You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feat]: Align the dependencies for binary and NPM artifact releases #4927
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.
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.
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.
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:
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.
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.
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.
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.
Activity
edvincent commentedon Mar 1, 2022
Some very quick digging around this so far: A common way to solve this is the
shrinkwrap.jsonfile - 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.lockfile, ornpm shrinkwrakcan be executed to get that.Now this is where it gets messy... Yarn doesn't honor at all the
shrinkwrap.jsonfile. 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 withnpm, and not withyarn.Here's some literature/discussion on this:
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 againstyarn global add code-serverlinking to yarnpkg/yarn#838.jsjoeio commentedon Mar 1, 2022
Good to know! Thanks for the literature/discussion. @code-asher do you know if there's any reason we've previously suggested using
yarnovernpm? Do you have any concerns with only suggestingnpm?One pro would be that it's one less dependency the end user needs to install since
npmcomes withnodewhereasyarnis always installed in addition.jsjoeio commentedon Mar 7, 2022
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:
code-asher commentedon Mar 8, 2022
These links are very helpful, thanks!
I vaguely recall issues installing code-server with
npmbut 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 commentedon Mar 8, 2022
Ah whoops I had not yet read your comment on #4918 about release size increasing with the
package.jsonmethod (that mergely link is awesome). With that in mind shrinkwrap does seem optimal.edvincent commentedon Mar 8, 2022
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 commentedon Mar 22, 2022
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 commentedon Mar 23, 2022
Heck yeah! Thank you so much for following up and doing this! We really really appreciate it.