Repository navigation
Conversation
latest from upstream
allow outputPath as a default value in angular-cli.js for all commands to use. Allows for a consistent way to specify where commands should output artefacts or look for them.
add utility functions for commands
add output path flag to test command, allowing default to be overridden.
add build command to replace default build command to allow for output path default.
add serve command to replace default serve command to allow for output path default.
add output path flag to deploy command, allowing default to be overridden.
add output path flag to init and new command, allowing a default output-path to be set on initialising a project
|
for build, test, serve commands unit testing them doesn't feel appropriate due to having to have a proper project initialised to test and will slow down the acceptance tests a lot I think. I can do it as e2e tests, would prefer me to add it to the existing basic workflow e2e or create new e2e tests? |
| }, { | ||
| name: 'output-path', | ||
| type: String, | ||
| default: 'dist/', |
There was a problem hiding this comment.
This has access to the config.
There was a problem hiding this comment.
I added the flag for flexibility, there was a use case where someone wanted to have different environments build to folders, having a flag would allow this. If you still feel it is unnecessary I'm happy to back it out.
There was a problem hiding this comment.
Too many flags will be confusing to new users using ng --help. I say having it in the config is enough. I do think it's unnecessary.
There was a problem hiding this comment.
ok np I'll back it out
There was a problem hiding this comment.
just another thought on this if we remove it there will not be a default value for outputPath if it's not set in the config file. I can handle this in CommandHelper.loadDefaults by making sure outputPath has a value.
Do you have any issues if I do it this way?
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
|
CLAs look good, thanks! |
|
Heya @JonCubed, we ended up implementing this in other PRs. I'm sorry we didn't take yours in, but thank you for all the work you put into it! |
pull request for #817