Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
edvincent opened this issue Mar 1, 2022 · 8 comments · Fixed by #5010
Closed

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

edvincent opened this issue Mar 1, 2022 · 8 comments · Fixed by #5010
Labels
enhancement Some improvement that isn't a feature
Milestone

Comments

@edvincent
Copy link
Contributor

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 edvincent added the enhancement Some improvement that isn't a feature label Mar 1, 2022
@edvincent
Copy link
Contributor Author

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:

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
Copy link
Contributor

jsjoeio commented Mar 1, 2022

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
Copy link
Contributor

jsjoeio commented 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:

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

@code-asher
Copy link
Member

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
Copy link
Member

code-asher commented Mar 8, 2022

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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 jsjoeio modified the milestone: April 2022 Mar 22, 2022
@jsjoeio
Copy link
Contributor

jsjoeio commented Mar 23, 2022

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

@jsjoeio jsjoeio modified the milestones: April 2022, 4.3.0 Apr 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Some improvement that isn't a feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants