[Feat]: Align the dependencies for binary and NPM artifact releases

[edvincent]

This issue is to continue the discussion from #4918 regarding the different release methods of code-server, and how NPM artifacts work.

What is your suggestion?

• Be in a state where the builds and installs are both deterministic when it comes to dependencies.
• Avoid having the dependencies being figured out at install time of the NPM package.

Why do you want this feature?

Right now, there's inconsistency on what dependencies might get used for the binaries generated (because they get generated after installing and building the package - which is an action that does respect the yarn.lock file) and the NPM artifacts (because the lockfiles are not published, nor the lockfiles for dependencies gets respected even if published).

This causes problems of dependency drifts like what was seen in #4900 - where releases might use different versions or worse, something working on release stops working because of newer versions being published.

Are there any workarounds to get this functionality today?

Not for the end-user. Specific versions can be pinned under the package.json file in this repo, but not something controlled by the end-user.

Are you interested in submitting a PR for this?

Yes

[edvincent]

Some very quick digging around this so far: A common way to solve this is the shrinkwrap.json file - which can be published and is literally meant for this use-case of distributing things that can be ran.

There are tools that allow to translate that file from a yarn.lock file, or npm shrinkwrak can be executed to get that.

Now this is where it gets messy... Yarn doesn't honor at all the shrinkwrap.json file. This doesn't matter for code-server builds/developers itself - but relying on this as a solution would mean that users should only ever install code-server with npm, and not with yarn.

Here's some literature/discussion on this:

• Shrinkwrap file from added packages are ignored  yarnpkg/yarn#838
• Avoid yarn for packages for now and fully enjoy its benefits for application development

This could work with a change of docs in https://coder.com/docs/code-server/latest/npm#installing to encourage using npm install -g code-server, and explicitly warning against yarn global add code-server linking to yarnpkg/yarn#838.

[jsjoeio]

Now this is where it gets messy... Yarn doesn't honor at all the shrinkwrap.json file. This doesn't matter for code-server builds/developers itself - but relying on this as a solution would mean that users should only ever install code-server with npm, and not with yarn.

Good to know! Thanks for the literature/discussion. @code-asher do you know if there's any reason we've previously suggested using yarn over npm? Do you have any concerns with only suggesting npm?

One pro would be that it's one less dependency the end user needs to install since npm comes with node whereas yarn is always installed in addition.

[jsjoeio]

I don't know if this would be covered by this issue or should be a separate but @code-asher and I were talking about having a npm workflow that runs each night to check that the npm release works as expected. Maybe something like:

1. install npm/yarn
2. install code-server
3. run e2e tests again code-server installed locally

[code-asher]

These links are very helpful, thanks!

I vaguely recall issues installing code-server with npm but they may no longer be valid.

So with that said, I think using the shrinkwrap file and encouraging npm (and even discouraging yarn plus the warning) is a great idea.

I would also be down to pin all the versions in the package.json; this seems to reflect our true intent anyway! But maybe this is only really necessary for alpha packages like Express 5.

[code-asher]

Ah whoops I had not yet read your comment on #4918 about release size increasing with the package.json method (that mergely link is awesome). With that in mind shrinkwrap does seem optimal.

[edvincent]

Awesome, was waiting for a sanity check on the approach. Will send a PR to generate a shrinkwrap file + updating the documentation to warn against yarn sometime this week.

[edvincent]

Ok, ended up being a bit later than that week (holidays were needed 😂) but sent a proposal to brainstorm/discuss what can be done. Happy to re-think the approach, but at least gets the discussion going.

[jsjoeio]

Heck yeah! Thank you so much for following up and doing this! We really really appreciate it.