Add dependency management #32
Conversation
DXJ-73 Ability to override aqua cli version
fluence dependency aqua --use recommended (will use hardcoded version. Used by default) fluence dependency aqua --use 0.1.2-323 (will use the version that you provided) fluence dependency aqua --version (return current version) fluence dependency --use recommended (all dependencies will be stable) store this info at ~/.fluece/dependencies.yaml also remove download confirmation and replace message with |
src/lib/typeHelpers.ts
Outdated
| @@ -43,3 +43,11 @@ export const assertHasKey: <K extends string>( | |||
| throw new AssertionError({ message }); | |||
| } | |||
| }; | |||
|
|
|||
| export const getIsStringUnion = | |||
There was a problem hiding this comment.
Please provide a comment explaining what does this function do.
There was a problem hiding this comment.
I will provide a comment and I know a way to make it look a bit better
src/lib/npm.ts
Outdated
| { recommendedVersion: string; bin: string; packageName: string } | ||
| > = { | ||
| [AQUA_NPM_DEPENDENCY]: { | ||
| recommendedVersion: "0.7.4-322", |
There was a problem hiding this comment.
What is our policy regarding aqua version? What if a new version, say 0.7.4-323 gets released? Should we update it here as well and bump the version of Fluence CLI? Or should we consolidate changes? Does it also mean that Fluence CLI version will depend on version(s) of it's deps?
There was a problem hiding this comment.
So basically I wanted our users to have a predictable experience so I decided to hard-code aqua version that I checked is working correctly with Fluence CLI and also give user this command fluence dependency which allows to override recommended version of the dependency
The idea is we allow aqua cli developers to do whatever breaking changes they want and we need to check if the new version is working and update this version each time we release. I think it's safer to do it like that, but user still
has flexibility to switch aqua cli version if he wants to
There was a problem hiding this comment.
Sounds reasonable. I still think It would be a good idea to extract the version string into some dedicated file, so it would be easier to spot the exact place where dependencies are specified. Once the dependencies are separated we would be able to live with such structure for a while and see if it would be possible to improve.
No description provided.