GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||
GeezerVison is showing github.com — Schematic with multi select x-promt errors when using command line parameter: 'path ".foo" should be array' · Issue #16320 · angular/angular-cli Open Labels area: @angular-devkit/schematics-clifreq1: lowOnly reported by a handful of users who observe it rarelyOnly reported by a handful of users who observe it rarelyseverity3: brokentype: bug/fix Milestone Description🐞 Bug reportCommand (mark with an
|
| throw new InvalidInputOptions(options, result.errors || []); |
InvalidInputOptions seems to be called with an object of {"name":"paul"} instead of: {"name":["paul"]}hey @alan-agius4 do you think this issue will be faced before releasing Angular 10? I tried to understand the implementation and would like to contribute but I didn't find out how to debug it until now ^^
@alan-agius4 sorry, I meant Angular 9 in the above comment.
@d-koppenhagen, currently this is not a top priority for the team.
@alan-agius4 I see. Meanwhile I dounf out how to debug and install the CLI locally. I found the place where the error occurs. I provided a PR (#16985) to fix it.
I don’t think that PR addresses the above issue. In the above issue you are using schematics CLI, however the fix is for Angular CLI.
Yes that’s true. But with the fix and building the CLI locally, the described issue doesn’t appear. So I think it will fix it indeed.
In the issue I just use the schematics CLI during the schematics development. But in the end I will run the schematic with the Angular CLI using ng add.
For anyone interested, the current workaround works for me:
schematics .:hello --debug=false --name=paul --name=peter
(tested with Angular CLI: 11.2.12)
Same problem
(We're using Angular CLI v17.3.8)
We're having the same problem in our open source library Spartacus, when our users run our installation schematics (ng add) with a command line option --features that has a type: array. See the following screenshot:
Workaround: first npm-install; then ng-add
Interestingly, the error doesn't happen at all, if I first manually npm-install the pacakge and only then run the same ng add command (with array) option.
Why the problem seems to happen
The problem of mis-interpreting the command-line option as a string instead of array seems to occur, because the anticipated schema.json of our package (which informs that a flag --features is type: array) is not known at the time of parsing the command-line arguments.
As far as I could NodeJS-debug the whole process, AngularCLI command ng add seems to work in the following way:
- first it parses the command-line arguments early, without knowing the
schema.jsonof the package that we're going to add - then it npm-installs the package (which means also downloading its schema.json)
- then it validates lately if the parsed command-line arguments match the expected type defined in the downloaded
schema.json
Above workaround doesn't work when passing the exact version ⚠️
The above mentioned workaround (i.e. first npm-installing the package before running ng add) doesn't work, when I pass the exact version of my package in the ng add command. See the following screenshot:
Our plan to resign from type: array
We plan to resign from using type: array (as it seems to be a bug in Angular that we cannot fix ourselves) and use type: string with comma-separated values by convention, e.g. --features="Cart, Order, Checkout". Then in the logic of our installation schematics, we plan to split the strings by comas and therefore have an array effectively.
Idea for a fix in Angular?
@alan-agius4 Do you think AngularCLI could re-parse the command line arguments lately, i.e. after the added package is already npm-installed, so the schema.json of the added package (informing which params are type:array) is really taken into account?
Hi @alan-agius4
If possible, I'd happy to provide a PR with a fix. My proposed approach is to re-parse the CLI arguments after the package is npm-installed so to we could use the package's precise schema.json for determining properly the types of arguments (e.g. array instead of string).
TBH I'd need a bit of an advice, how we could possibly workaround the limitations of the current architecture.
Let me share my understanding of the current architecture:
- there is an inversion of control: we plug our commands (in this case
AddCommandModule) into theyargstool (source) by exposing 2 "template methods":build()andrun()in ourAddCommandModule yargswill invoke those 2 methods:- first it will invoke
build()- it's the only time, when we can access thelocalYargsobject and instruct it on how to parse the raw CLI arguments like['ng', 'add', '@my/lib', '--features=foo', '--features=bar']- especially by calling the convenient methodlocalYargs.option(<optionName>, ...) - then it invokes
run()(viahandle()method) - then we no longer have access to the parser objectlocalYargs, but we have access only to the already-parsedoptionsobject. There we npm-install the package (if needed) and then we execute its schematics with passing those already-parsedoptionsobject.
- first it will invoke
Do you have any idea of a workaround how we could re-parse the raw CLI arguments (i.e. invoke this.addSchemaOptionsToCommand() in the run() function, after npm-installing a package but before executing the schematics? Thanks to this, we could pass properly interpreted options object to the executed schematics (e.g. --features=foo --features=bar parsed to an array features: ['foo', 'bar'], instead of a string features: 'bar').
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Issue actions
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.