RFC 4 - Automatically calculate aliased major version when alias not explicitly supplied

[digitalsadhu]

This PR addresses the question of whether omitting the alias should result in a default.

For example. Given the following eik.json file:

{
  "name": "my-app",
  "version": "5.3.1",
  ...snip
}

If the user were to run eik package-alias rather than being explicit with (eik package-alias 5), should the command assume v5?

Use cases

Both Troika and Fabric currently automatically update the alias after publishing a new version. They essentially "front foot" the process of updating the alias but make it possible to manually roll back to an earlier version if necessary. For more input on this I think @alexanbj and @stipsan (if he's around) could offer more.

For me, the question of whether this is a feature we want, is only a matter of whether the use case is valid, which is to say, if it is valid, and we don't implement this within the eik cli, setups such as for troika and fabric will end up having to do this work manually themselves which is tedious within a bash script or npm script context.

So, the question is, is it valid as a use case to automatically update aliases after a publish? If so why? If not, why not?

Discuss!

[pearofducks]

👍

Outside of being useful for modules like Fabric, we would also use this to make it easier to configure asset public-paths.

e.g. in rollup:

rollupPluginURL({
      destDir: 'dist/assets',
      fileName: '[name][extname]',
      publicPath: 'https://assets.myserver.com/pkg/my-eik-project/v0/',
})

[stipsan]

So, the question is, is it valid as a use case to automatically update aliases after a publish?

Yes, in the context of a CI pipeline it's even preferred. It doesn't make sense to allow automation for every step except this one. It'll encourage brittle setups like the one in Troika. It's brittle as in the way it extracts the major version that it uses in the script will only keep working correctly as long as troika don't hit a v10. Yes it's unlikely troika will ever hit that many majors, especially now with Fabric replacing it. But the point is there's a lot of value by eik providing this functionality.

Another thing to consider why it's a good API design to have the default behavior be using the major version from the eik json instead of always specifying it: If you're already using the alias feature, think about how many times you'll fire the eik package-alias command and specify the same version that's in eik json compared to all the times you'll give it a different version. I think that the only times you'll actually want to alias to a different major is probably going to be on an canary/alpha/beta/prerelease. And you can probably count them on one hand.