Support Yarn 3 workspaces #3668
eric-burel
started this conversation in
Proposals
Replies: 1 comment 1 reply
-
@eric-burel Could you please explain why you need |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey folks, I maintain a stack in a monorepo (https://github.com/VulcanJS/vulcan-npm) that contains a Next, an Express and a Remix boilerplate alongside multiple packages.
The issue I have, is that if you define your Remix app as an independant workspace, it cannot have a
yarn.lock
file, otherwise it disable Yarn package hoisting (which is the whole point of having a monorepo in the first place).You could simply run
yarn
in your Remix folder, but then versions will be inconsistant, it's not acting as a lock anymore.So you need to find a way to generate a
yarn.remix.lock
based on the big, rootyarn.lock
which will include all dependencies of your app.I've added documentation to this Yarn plugin that can generate
yarn.lock
for workspaces of a monorepo: https://github.com/JanVoracek/yarn-plugin-entrypoint-lockfilesIt will read your big root
yarn.lock
, your Remix apppackage.json
, and generate ayarn.remix.lock
with the right packagesI've commented on the parent issue of Yarn (which doesn't support this out of the box sadly) Individual lockfile per workspace yarnpkg/berry#1223 (comment)
This PR demoes our implementation in Vulcan: Feature/starters lockfiles VulcanJS/vulcan-npm#132
It extends to other frameworks as well. I could finally run Remix CI actions (the ones defined in the Indie stack) correctly with this approach and a few tweaks.
It's very far-fetched, but needed if you want to publish a Remix stack from a monorepo.
Related: #2474 for NPM workspaces, #683 for yarn 3 bugs, PR to support pnp #1316
Beta Was this translation helpful? Give feedback.
All reactions