Dpetev/yargs bump 10.1.x #1096

damyanpetev · 2023-01-26T17:40:28Z

Closes # .

Additional information related to this pull request:

coveralls · 2023-01-26T18:06:32Z

coverage: 70.141% (-0.02%) from 70.158%
when pulling 884d841 on dpetev/yargs-bump-10.1.x
into 6e8b984 on 10.1.x.

damyanpetev · 2023-02-07T16:26:01Z

@PlamenaMiteva @Lipata
The changes in the PR are for the most part bumping yargs to latest, though I'm assuming there are yarn.lock diffs in latest and it might not be feasible to reuse this PR and might need to be recreated. If not, this could also be retargeted just as easily.

If useful here are the steps and some issues I found along the way that need to be resolved.

yarn workspace igniteui-cli add yargs@latest

And since we didn't have those, I figured types would be nice and help with the migration process, so also

yarn workspace igniteui-cli add @types/yargs@latest --dev

And they sort of did, the notable change being that .parseSync() is now needed to go back to the old behavior we used. However, there's an issue with the options we pass to .command(), because our objects contain extra stuff and thus the multiple as any type asserts in the PR. I believe those confuse the overload matching and it ends up going for a different version, though the type errors might be perfectly valid too - needs to be checked against typing and docs and adjusted.
PS: If we update TypeScript satisfies looks nice :)

One more thing I landed on - the typescript-json-schema we use for the config schema failed trying to parse the new yargs type (which is why I reverted those to see if the build will work). Tried updating, though that didn't help - might be reliant on the typescript version itself so update there might be needed. There's also the question of why was the schema trying to parse the yargs types in the first place - there's a good chance it's better to run it with its own config which is possible looking at the docs, cuz I'm pretty sure it doesn't need to use those types to produce the schema for a few of our interfaces.

Lastly, not sure if it's just on my end, but I can't run tests locally due to lint fails which mysteriously don't happen on the build machines. @Lipata this might be a separate task/issue, but there's something wrong with the lint setup, ignoring the fact that tslint should be replaced with eslint too.

github-actions · 2023-04-08T22:40:16Z