Hello. I’ve read a few older posts in this forum regarding RedwoodJS Projects in Monorepos, but none seem to help me with my particular issue.
A RedwoodJS project by default utilizes yarn workspaces for the api and web sides of the project and defines the
nodeLinker in the
.yarnrc.yml file as
node-modules. With this configuration, the RedwoodJS project, web, and api sides expect the installed dependencies to live in specific places (assuming default
My issue is that I’m trying to nest my RedwoodJS project (which is a workspace) inside of my monorepo and include that in the top-level workspace. My goal for this is so I can start to use shared libraries in my top-level
libraries/ directory like other non-RedwoodJS projects in my monorepo’s workspace.
My top-level workspace sets the
workspaces as all the projects in the monorepo aren’t setup to search outside the project directory for their dependencies. Because of this, I’ve tried overriding the hoisting limit within my nested RedwoodJS project by updating the
installConfig within the Redwood package.js, but no matter which value I use, my RedwoodJS project either fails to compile or fails at runtime due to issues finding certain dependencies.
I’m open to other alternatives to solving code sharing between my RedwoodJS project and other projects within the same git monorepo, but I’m looking to limit the addition of new tooling if vanilla yarn workspaces can solve the problem. The only requirement I have is that my CI/CD pipeline can continue to work by installing dependencies within the respective project directories.
It’s worth pointing out that the way my other projects consume a shared library is by defining a similar line to this in their
"shared-library-1": "workspace:*". The benefit is that these dependencies are symlinked allowing a quick feedback loop for changes without needing to run
yarn install again.
As a follow-up, I’ve tried following the steps in this other forum post, but it only works when running
yarn rw dev - attempting to run
yarn rw test results in errors.
I updated my root workspace to use the default hoisting limits of
none everywhere, but continued to have issues with my redwood project.
I feel your best bet is just to have separate Yarn repos and use Yalc for working on your libraries.
We use it on the dbAuth OAuth plugin. That plugin’s repo actually has a Redwood project in it, and the way we were able to get that to work was by having it as a separate workspace, so you could do a monorepo in that way if you wanted.
Another option is to have a normal Redwood project, and then include and libraries you might be working on within it - so you’d have
packages/* as a workspace on the same level as your Redwood sides.
Thanks for the suggestion! I’ll look into
yalc to see if I can use it to share dependencies at a level higher than my Redwood project. It makes sense for the project I’m working on to not be the root of the repo as it’s only one product out of a few.
@arimendelow, I’m curious if you can speak a bit more about the development workflow you might exhibit when using
yalc for the
dbAuth plugin. (I couldn’t see any references to
yalc anywhere unless I’m missing something).
From reading the
yalc link you provided, it seems like during development I might be able to use
link command to have changes immediately available from my monorepo top-level shared libraries. The CI/CD workflow is less clear to me, though - I think I would need to manually navigate to each shared library I want to use, build, and publish with
yalc before I can use
yalc add in my redwood project. Does that sound right?
Sorry for the delay - if you look at the package.json files, you’ll see where I’m using Yalc: https://github.com/spoonjoy/redwoodjs-dbauth-oauth/blob/73c14fd058b2fdd2e2dd22c26d61e7dc569c92d4/web/package.json#L27C1-L27C43
And yeah, that’s correct. You’ll need to rebuild/publish after you make any changes - it’s not perfect, but it’s workable.
One more thing - don’t use Yalc for prod. For production, publish your packages to some repo (npm or a private one), and use it from there.
No worries! Thanks for the link and the info. I’ll start looking into this!
Of course!! Let us know if you run into any other issues