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 nmHoistingLimits of none).
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 nmHoistingLimits to 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 package.json files: "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.
1 Like
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?
1 Like
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.
1 Like
No worries! Thanks for the link and the info. I’ll start looking into this!
1 Like
Of course!! Let us know if you run into any other issues 