FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[Feat]: Align the dependencies for binary and NPM artifact releases · Issue #4927 · coder/code-server · GitHub

Repository navigation

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

Closed

Description

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

Activity

  1. edvincent commented on Mar 1, 2022

    ContributorAuthor

    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.

  2. jsjoeio commented on Mar 1, 2022

    Contributor

    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.

  3. jsjoeio commented on Mar 7, 2022

    Contributor

    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
  4. code-asher commented on Mar 8, 2022

    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.

  5. code-asher commented on Mar 8, 2022

    Member

    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.

  6. edvincent commented on Mar 8, 2022

    ContributorAuthor

    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.

  7. edvincent commented on Mar 22, 2022

    ContributorAuthor

    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.

  8. modified the milestone: April 2022 on Mar 22, 2022
  9. jsjoeio commented on Mar 23, 2022

    Contributor

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

  10. modified the milestones: April 2022, 4.3.0 on Apr 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementSome improvement that isn't a feature

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL