[Feat]: use npm run release:standalone

[jsjoeio]

What is your suggestion?

Use npm for release:standalone in CI.

Why do you want this feature?

It will respect our shrinkwrap file. See logs here:

warning npm-shrinkwrap.json found. This will not be updated or respected. See https://yarnpkg.com/en/docs/migrating-from-npm for more information.

Are there any workarounds to get this functionality today?

No

Are you interested in submitting a PR for this?

I can if no one else wants to.

[jsjoeio]

@edvincent tagging you because I think you'd find this interesting. Also maybe you want to help with this? If not, no worries :) Seems like a one-liner.

[edvincent]

That's the one where I was suggesting to use npm ci right? Happy to have a look yup, was already in my to-do from #5071 (comment)

As a side-comment, that error

warning npm-shrinkwrap.json found. This will not be updated or respected. See https://yarnpkg.com/en/docs/migrating-from-npm for more information.

is just cosmetic. In release:standalone in the CI, we have both a yarn.lock and an npm-shrinkwrap.json, so both yarn and npm could be used.

But yes, way better to start using npm ci to keep it consistent with what other users would use.

Can I sign-up to do this during the next week or so, or is this more urgent?

[edvincent]

Oh nvm, you mean actually use npm run to run the tests etc...? Because I think you already merged the one to install it with npm?

[jsjoeio]

Can I sign-up to do this during the next week or so, or is this more urgent?

that'd be awesome! absolutely no rush so whenever you have time :)

Oh nvm, you mean actually use npm run to run the tests etc...? Because I think you already merged the one to install it with npm?

Good question! Our thinking was to replace it here:

• https://github.com/coder/code-server/blob/main/.github/workflows/ci.yaml#L297
• https://github.com/coder/code-server/blob/main/.github/workflows/ci.yaml#L385
• https://github.com/coder/code-server/blob/main/.github/workflows/ci.yaml#L433

[edvincent]

So, I don't think we should do that? I think the line between yarn and npm should be development of code-server vs install of code-server itself.

Or in other words, any command starting from the root of the project (i.e. development) should be using yarn, and if during the development we need to install code-server (i.e. go within release or release-standalone), that's where we should use npm.

Which is basically the current state?

Specifically, because we don't have an npm-shrinkwrap.json tool at the root of the project.

That being said, since your #5533, we now should be clear to remove the yarn.lock (or more specifically, not rsync them into the nested directories) as we'll always use npm there?

[jsjoeio]

So, I don't think we should do that? I think the line between yarn and npm should be development of code-server vs install of code-server itself.

I do agree we should have the distinction. It would be nice if we used one instead of mixed them though. I wonder if instead we should move development to npm then 🤔 What do you think?

cc @code-asher

That being said, since your #5533, we now should be clear to remove the yarn.lock (or more specifically, not rsync them into the nested directories) as we'll always use npm there?

That makes sense to me!

[edvincent]

I do agree we should have the distinction. It would be nice if we used one instead of mixed them though. I wonder if instead we should move development to npm then 🤔 What do you think?

I don't think you can ;( Because vscode only comes with a yarn.lock file/expects yarn tasks... Actually, that being said, I believe the latest versions of npm respects the yarn.lock file.

I think that was the reason code-server was moved to use yarn back in the day no?

[jsjoeio]

I don't think you can ;( Because vscode only comes with a yarn.lock file/expects yarn tasks... Actually, that being said, I believe the latest versions of npm respects the yarn.lock file.

Ahhh I forgot about that 🤦🏼‍♂️

I think that was the reason code-server was moved to use yarn back in the day no?

That's before my time but I bet you're right.

[code-asher]

VS Code embeds yarn in a bunch of places so that might throw a wrench in some things, for example their postinstall and build scripts. There is also a check in their preinstall script that forbids the use of npm. This could all be patched of course but I am not sure we should.

Agreed on removing the yarn.lock rsync!

The npm-shrinkwrap.json found warning was confusing because it made it seem like we were using yarn to install the dependencies in the standalone release even though we run npm install so the thinking was that maybe yarn run provides an npm shim that actually runs yarn or something tricky like that.

I tested a bit and npm_config_user_agent shows yarn/1.22.19 npm/? node/v16.16.0 linux x64 (in the postinstall script) even though we install with npm install so we end up using yarn.

So maybe npm avoids overwriting that or maybe yarn does do some kind of trickery here. Using npm run is one fix but maybe there is a better one.