Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

vue ui build task gui ignores package.json --mode and --dest flags #3236

Closed
ediphy-dwild opened this issue Jan 2, 2019 · 10 comments
Closed

vue ui build task gui ignores package.json --mode and --dest flags #3236

ediphy-dwild opened this issue Jan 2, 2019 · 10 comments
Labels
enhancement scope: ui

Comments

@ediphy-dwild
Copy link

Version

3.2.1

Environment info

Environment Info:

  System:
    OS: Linux 4.9 Debian GNU/Linux 9 (stretch) 9 (stretch)
    CPU: (4) x64 Intel(R) Xeon(R) CPU @ 2.60GHz
  Binaries:
    Node: 11.6.0 - /usr/local/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.5.0-next.0 - /usr/local/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @vue/babel-preset-app:  3.2.0
    @vue/cli-overlay:  3.2.0
    @vue/cli-plugin-babel: ^3.2.0 => 3.2.0
    @vue/cli-plugin-e2e-cypress: ^3.2.0 => 3.2.0
    @vue/cli-plugin-eslint: ^3.2.0 => 3.2.1
    @vue/cli-plugin-pwa: ^3.2.0 => 3.2.0
    @vue/cli-plugin-typescript: ^3.2.0 => 3.2.0
    @vue/cli-service: ^3.2.0 => 3.2.0
    @vue/cli-shared-utils:  3.2.0
    @vue/component-compiler-utils:  2.3.1
    @vue/eslint-config-typescript: ^3.2.0 => 3.2.0
    @vue/preload-webpack-plugin:  1.1.0
    @vue/web-component-wrapper:  1.2.0
    babel-helper-vue-jsx-merge-props:  2.0.3
    babel-plugin-transform-vue-jsx:  4.0.1
    eslint-plugin-vue: ^5.0.0-0 => 5.0.0
    vue: ^2.5.17 => 2.5.21
    vue-awesome-swiper: ^3.1.3 => 3.1.3
    vue-class-component:  6.3.2
    vue-cli-plugin-vuetify: ^0.4.6 => 0.4.6
    vue-cli-plugin-webpack-bundle-analyzer: ^1.2.0 => 1.2.0
    vue-clipboard2: ^0.2.1 => 0.2.1
    vue-eslint-parser:  2.0.3
    vue-hot-reload-api:  2.3.1
    vue-loader:  15.4.2
    vue-property-decorator: ^7.2.0 => 7.2.0
    vue-resize-directive: ^1.1.4 => 1.1.4
    vue-router: ^3.0.1 => 3.0.2
    vue-style-loader:  4.1.2
    vue-template-compiler: ^2.5.17 => 2.5.21
    vue-template-es2015-compiler:  1.6.0
    vuedraggable: ^2.17.0 => 2.17.0
    vuejs-storage: ^0.9.0 => 0.9.1
    vuetify: ^1.3.0 => 1.3.15
    vuetify-loader: ^1.0.5 => 1.0.8
    vuex: ^3.0.1 => 3.0.1
  npmGlobalPackages:
    @vue/cli: 3.2.2

Steps to reproduce

  • open the vue ui web dashboard
  • import a project containing eg
  • "build:dev:webapp-shared": "vue-cli-service build --mode devshared --dest shared-dev-build/dist --no-clean"
    • (note that the script command at the top right of the gui does include all the command line params in the package.json)
  • click 'Run task'

What is expected?

--mode and --dest flags visible in the script command (from package.json) view are honored

What is actually happening?

builds ignore the script command --mode, and will override --dest to 'dist'. --dest can be worked around by opening the 'parameters' dialog, but --mode cannot be worked around, and the task gui cannot be used to run this build task.

  1. the dest is being set to a subdirectory within shared-dev-build as we use a docker volume as the destination for the build, and if a raw 'dist' is mounted, the directory cannot be deleted at the start of the build (from memory, a rmdir command fails), so we worked around this by mounting a higher directory, and having the build take place in a subdirectory of the mountpoint.

  2. the overriding appears to be driven by the defaults in the 'parameters' dialog
    further to this:

open the parameters window

  • note that 'Output directory' is 'dist' (this can be overridden manually by copying and pasting the desired dest from the script command)
  • note that the 'Specify env mode' is a dropdown and cannot be overridden with the desired 'devshared' mode, so we are stuck with one of the three predefined modes
@Akryum
Copy link
Member

Akryum commented Jan 2, 2019

You should use the (unset) value so it doesn't override the mode.

@Akryum
Copy link
Member

Akryum commented Jan 2, 2019

Maybe the Parameters dialog should have a Override hardcoded parameters switch and grey out hardcoded parameters in the prompt list.

@ediphy-dwild
Copy link
Author

I feel that making the textbox, which acts as a command-preview - match what the Run button will do when clicked would be of greater benefit than enhancing the gui to fit my particular use-case.

A secondary issue is that running a build task from the command line, then running the same build task from the gui produces different results.

@katerlouis
Copy link
Contributor

What's the status on this one?
Would like to stay in the UI for this task and rely heavily on environment variables.

@jawa-the-hutt
Copy link

Adding to this as I was just testing something last night with 3.4.1 doing a serve and --mode development.web parameter essentially looks like it came across as just --mode development in the ui. Everything works fine in the command line.

The command preview in the UI shows --mode development.web correctly, but what's ending up in api.service.mode is just development

@Akryum
Copy link
Member

Akryum commented Mar 11, 2019

See #3236 (comment)

@jawa-the-hutt
Copy link

Thanks @Akryum. I saw that up there but didn't really clue into what it was and had no idea how to use it. did some research and found it in the UI and it fixed my issue.

@jawa-the-hutt
Copy link

jawa-the-hutt commented Mar 11, 2019 •
edited
Loading

One related question.

I had just been relying on the UI reading the npm scripts and bringing those in as tasks. I know we can build out our own Tasks for UI purposes to effectively mirror what's in npm scripts. I didn't do this originally as I didn't want to maintain something in two places.

Is there a way to programtically pass in the unset option from npm scripts? If not, then it seems the options are:

  1. Ask the user to make sure they use the unset option in the UI. Which we'd have to provide as documentation to them.
  2. Build out the tasks to mirror what's in npm scripts and pass in explicit mode options. Any changes need in one or the other would need made in both.

Do I have that basically correct?

edit:

The reason I didn't go down the route of maintaining both is we have a dozen or so npm scripts that would need mirrored as it's a plugin to integrate Nativescript-Vue with CLI 3. I realize that's a lot of Tasks to have in the UI, but we're trying to mirror a lot of the existing CLI options that Nativescript offer.

@savokiss savokiss mentioned this issue Mar 19, 2019
Closed
@Akryum Akryum mentioned this issue Apr 13, 2019
Closed
@Akryum Akryum closed this as completed in bbe4002 Apr 13, 2019
@Akryum
Copy link
Member

Akryum commented Apr 13, 2019

image

@katerlouis
Copy link
Contributor

Nice change!
Still wondering if it would be possible to go a step further and weave the hard-coded settings right into the ui, so that when I open the dropdown for mode, it shows an option with the hardcoded --mode.

That option could be preselected, until the user changes it.

This would enable the user to keep some variables coming from the hard-coded script, and change only some others, and not all.

@katerlouis katerlouis mentioned this issue Apr 14, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement scope: ui
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jawa-the-hutt @katerlouis @Akryum @ediphy-dwild