Open d-koppenhagen opened 4 years ago
This is somewhat related to https://github.com/angular/angular-cli/issues/12150 but in this case it's for Array's
It seems that the cause of this error is somewhere in validateOptionsWithSchema
:
https://github.com/angular/angular-cli/blob/fd6bba38a008c6ff89584c3edf8ff5ab326f51d1/packages/angular_devkit/schematics/tools/schema-option-transform.ts#L43
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 (https://github.com/angular/angular-cli/pull/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)
(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:
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.
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:
schema.json
of the package that we're going to addschema.json
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:
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.
@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:
AddCommandModule
) into the yargs
tool (source) by exposing 2 "template methods": build()
and run()
in our AddCommandModule
yargs
will invoke those 2 methods:
build()
- it's the only time, when we can access the localYargs
object 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 method localYargs.option(<optionName>, ...)
run()
(via handle()
method) - then we no longer have access to the parser object localYargs
, but we have access only to the already-parsed options
object. There we npm-install the package (if needed) and then we execute its schematics with passing those already-parsed options
object.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'
).
π Bug report
Command (mark with an
x
)Is this a regression?
No, it's not. Multi select prompt is just supported within angular cli >
9.0.0-rc.3
.Description
Creating an angular schematic that prompts the user for multiple options is possible since https://github.com/angular/angular-cli/issues/16104. The prompt works quite good now but using the command line for multi selections will cause an error:
At first I opened an issue for the docs because I thought it's just not documented: https://github.com/angular/angular/issues/33851 But after checking the implementation of the angular guard schematic which has
--implements
parameter (which works) and creating the minimal reproduction repo (see underneath), I think it's a bug somewhere in@angular-devkit/schematics-cli
.π¬ Minimal Reproduction
I created a very minimal repo for reproduction: https://github.com/d-koppenhagen/ngx-multi-select-schematic
β Using prompt works good:
βUsing command line parameter fails (event not with just a single name handed over:
π₯ Exception or Error
π Your Environment