Upgrade to Yarn v4 (Berry) #3095
Conversation
It's not generally available in browser environments / certain Yarn modes and can easily be replaced by TextEncoder.
This sounds really nice. Since this is basically a full package manager change I feel like it would be appropriate to do a bit of research and collect pro/cons to other alternatives and not make the decision an artifact of us not being able to compile with vite dev. |
| If you want to make changes to a package that Element Call depends on and see those changes applied in real time, you can create a link to a local copy of the package. Yarn has a command for this (`yarn link`), but it's not recommended to use it as it ends up modifying package.json with details specific to your development environment. | ||
|
|
||
| Instead, you can use our little 'linker' plugin. Create a file named `.links.yaml` in the Element Call project directory, listing the names and paths of any dependencies you want to link. For example: | ||
|
|
||
| ```yaml | ||
| matrix-js-sdk: ../path/to/matrix-js-sdk | ||
| "@vector-im/compound-web": /home/alice/path/to/compound-web |
There was a problem hiding this comment.
I am loving this.
Do I understand it correctly, that it just allows us to put this part of the package.json into its own file, so that we can git-ignore it?
pnpm has the same behaviour and I was wondering how this could be elegantly solved.
This is great!
There was a problem hiding this comment.
Yes, though I just realized that this method will still modify yarn.lock, sigh. I don't know of a better solution right now.
| @@ -297,7 +296,7 @@ export class PosthogAnalytics { | |||
| const posthogIdMaterial = "ec" + accountAnalyticsId + client.getUserId(); | |||
| const bufferForPosthogId = await crypto.subtle.digest( | |||
| "sha-256", | |||
| Buffer.from(posthogIdMaterial, "utf-8"), | |||
| new TextEncoder().encode(posthogIdMaterial), | |||
There was a problem hiding this comment.
is this needed for the yarn berry switch or just randomly here?
There was a problem hiding this comment.
I was trying out Yarn's plug-n-play mode, and it needed this change. I reverted to the normal node_modules linker so I don't think it's strictly necessary. Would you prefer I exclude it?
There was a problem hiding this comment.
n.b. This would need a corresponding PR for https://github.com/element-hq/element-call-webapp-deployments/blob/main/.github/workflows/deploy.yml to enable corepack
|
This depends on https://github.com/element-hq/element-call-webapp-deployments/pull/3 then, so marking as blocked. |
robintown
added
X-Blocked
I had a look at whether switching to npm or pnpm would be possible. At first, I was under the impression that either would work for us, but it turns out that their handling of Git dependencies is subtly broken.
So Yarn appears to be the only package manager out there that handles Git dependencies in a reasonable way, as of now. I think this is a good example of the Yarn project's commitment to stability & correctness around edge cases, which is a reason I would've advocated for it even if npm/pnpm were equally viable. It's a package manager's best feature :) Bun is another alternative, but I haven't tried it out because switching to an entirely different JS runtime seems like a far deeper rabbit hole. |
|
@robintown Thank you for going the extra mile of looking into this and providing us with a specific reason/reasons why we want to go that path. |
#3093 presents a dilemma: We want to consume matrix-js-sdk via its build artifacts, but we also want to continue using development versions of matrix-js-sdk (pinned to Git commits) rather than releases. Development versions, of course, don't come with build artifacts. This threatens to complicate the build process for developers, packagers, CI, everyone. (Now you would always need to clone & link matrix-js-sdk, cross-reference our package.json, check out the right commit, and build it separately.)
The good thing is, modern package managers have figured out a far more elegant way to support this use case: if a Git dependency contains a
prepackscript, they will run that script before installing the package intonode_modules, making this the perfect way to automatically perform a build step. In fact, matrix-js-sdk already has this exact script! We just can't benefit from it as long as we're stuck using Yarn Classic, which hasn't been actively developed for years.I suggest that now would be as good a time as any to upgrade from Yarn Classic to Yarn v4 (Berry). The Yarn developers put a lot of thought into making the
yarncommand automatically invoke the right version of the tool depending on the repository you're in, so switching between Yarn Classic and Yarn Berry repositories is a pretty seamless experience. The only obstacle to upgrading that I encountered is that Yarn Berry regresses the developer experience of working with linked packages. However, I believe I've remedied this with a plugin I threw together.Any reservations on making such an upgrade?
For #3081
Depends on https://github.com/element-hq/element-call-webapp-deployments/pull/3