Package Resolution

[minkimcello]

✨ TL;DR: See conclusion section at the bottom.

Covector currently offers date and sha as options for preview package version templating:

1.0.0-my_branch.abcdefg       <== sha
1.0.0-my_branch.20201012123   <== date

And we're trying to re-visit the idea of using incremental versions:

1.0.0-my_branch.0
1.0.0-my_branch.1
1.0.0-my_branch.2
1.0.0-my_branch.3

🟦 yarn 1.22.11 because 2 is 🗑

yarn add package@tag will resolve to the caret version of the last tag that was published

yarn publish 1.0.0-feature.1    <== first
yarn publish 1.0.0-feature.0    <== afterwards

so in this ☝️ example where we publish .0 after .1, running yarn add package@tag will update your package.json to

{
  "dependencies": {
    "package": "^1.0.0-feature.0"
  }
}

and this will actually install .0 and not .1 despite the caret. at yarn version 1.22.11, running yarn --force will not fetch .1 either. in order for the caret to "work", you would need to delete your lockfile and run install again at which point it will finally evaluate .1.

if 1.0.1 exists, running yarn add package@tag will still install 1.0.0-feature.0 until you remove the lockfile and run install at which point you'll finally get 1.0.1.

🟥 npm 6.14.9

the tag mechanism seems to work the same way in npm. running npm install package@tag will grab the last tagged version regardless of its number. but unlike yarn --force, npm update will actually fetch the latest package versions without having to delete the lockfile:

npm install package@tag      <== [email protected]
npm update                   <== [email protected]

hard set with tag

alternatively, instead of running yarn add package@tag or npm install package@tag, you can update your package.json manually to use the tag (and not have it resolve to a careted version of the tag):

{
  "dependencies": {
    "package": "tag_name"
  }
}

this will always resolve to the most recent tag regardless of if you're using npm or yarn. so in our example, it will always install 1.0.0-feature.0 no matter what. even if 1.0.1 is available and even if the current lockfile has the package locked at 1.0.1, if you set the version of your package to the tag, it will resolve to last tag published (.0 in our example).

Conclusion?

npm install package@tag
yarn add package@tag

☝️ Will both grab the last published tag version (1.0.0-feature.0) and not the "highest" (1.0.0-feature.1). Both will set the package version to ^1.0.0-feature.0 in your package.json. With npm you can run npm update, with yarn it seems you must delete the lockfile and run yarn install again.

{
  "dependencies": {
    "package": "tag_name"
  }
}

☝️ Will always resolve to the last version that was published using the tag.

[minkimcello]

So as Charles suggested, I think we should go ahead and switch to incremental versioning.

The incremental versioning makes no difference if we hard-set the package version to just use the tag in our package.json. And it also makes no difference if we only run npm install package@version. But for any subsequent npm update, it would try and evaluate the caret and so using SHA would lead to the user installing the incorrect package.

I've expressed concerns of relying on incremental versions and how it might disrupt development for someone who is working with a preview package and hasn't had a chance to rebase. For instance:

1. preview package [email protected] is published
2. people start developing other features with that preview package
3. someone merges a version-packages PR and boop gets 1.0.1 published without the features from [email protected]
4. people that were using the preview package might run npm update to update other dependencies and would accidentally pull in [email protected] instead of 1.0.0-feature.1 which their PR was depending on
   • maybe a good developer might catch on quickly but for others it might take a while before they realize what happened

We discussed the option to publish prerelease versions using the base branch as a point of reference. So say I'm developing on 1.0.0 while the main branch gets a release and is currently on 1.0.1, the prerelease version would check the package version of the main branch and generate the preview by doing a patch bump and attaching the prerelease template 1.0.1 => 1.0.2 => 1.0.2-feature.0. I would imagine this would be a github-specific feature because I'm not sure what kind of payload would be available on other services but it would be easy to implement. However, this would not solve the problem of someone who was already consuming a preview package as there's no way to notify them saying "hey, you're using 1.0.0-feature.1 but 1.0.1 has been published. there's also a new preview package from the same tag (1.0.1-feature.0)`.

One possible workaround would be to have a preinstall (or postinstall) script yarn covector check to check all the dependencies to see which ones are trying to evaluate prerelease versions and report if it ended up resolving to a new patch bump? 🤷‍♂️