[Question] Can I use yalc in a "permanent" manner within a monorepo?
ctrlplusb opened this issue · comments
Love this lib, thank you!
I'm on a journey to create a monorepo that does not utilise any workspaces or hoisting features. Masochist, maybe? 😅 Long story, but I am over hoisting related issues.
I'd love to use yalc to help me manage cross package dependencies within my monorepo. I feel like yalc isn't really described for this case, in which it would be a "permanent" feature of the monorepo, rather than a temporary dev related workaround.
I've got it working, but my workflow needs to be ironed out a bit.
Has anyone else had experience in this respect? How do you enable seamless clones of a monorepo in which yalc is managing the cross dependencies? Do you commit yalc.lock files, and how do you rehydrate the store etc? I'm also interested in hearing about any consideration to make the push of updates more seamless.
Thanks ya'll.
In most cases I commit yalced packages into git. So, I use yalc as a way to install some "permanent" stuff in (usually monorepo) projects, the stuff that is managed by me, that is in dev mode and not published for a shared consumption.
Ah I see, so the .yalc folders that are local to each package, along with their yalc.lock files will be committed to git? I guess I could live with that yeah.
So it would be something like this right;
my-mono-repo
|- .git
|
|- apps
| |
| |- @my/mobile-app
| |- .yalc
| | |- @my/components
| |- src
| |- package.json
| |- yalc.lock
|
|- packages
| |
| |- @my/components
| |- src
| |- package.json
|
|- package.json
What about rehydrating a user's global yalc store? Say another team member does a fresh checkout. They would need to rehydrate the store right and somehow rebuild the installation tree so that they can do subsequent yalc push'es. Do you have a workflow around this too?
I feel like I almost want the yalc store to be local to the monorepo root, but then I am apprehensive to commit that to git too. 😅
Ah I see, so the .yalc folders that are local to each package, along with their yalc.lock files will be committed to git?
I prefer a single .yalc folder for a project.
What about rehydrating a user's global yalc store? Say another team member does a fresh checkout.
I don't think that yalc plays nicely with team's workflows.
I'm not sure what you are trying to accopmlish. For using packages across a monorepo I use workspaces feature. Yalc is for installing external stuff.
For using packages across a monorepo I use workspaces feature. Yalc is for installing external stuff.
Yeah, I'm explicitly trying to avoid workspaces. I don't want to leverage hoisting. My goal is to try to enable monorepo style development whilst utilising yalc to manage the dependencies between the packages of the monorepo.
@wclr - I'm riffing on some ideas for a complementary CLI on top of yours, which is specific to my usecase. The readme describes this theoretical package;
https://github.com/ctrlplusb/yalcd
What do you think? Any concerns or objections?
Readme driven development ™️
Yeah, I'm explicitly trying to avoid workspaces. I don't want to leverage hoisting.
What is the real problem with workspaces/hoisting? I usually use PNPM for managing monorepos.
@ctrlplusb It's pretty easy getting yalc to working sustainably for a monorepo.
For example I have a postinstall script setup:
"scripts": {
"postinstall": "yarn workspaces foreach exec yalc publish --push",
},
Then you yalc add in the projects you need it in and commit the yalc.lock file and ignore the .yalc folder.
Now whenever you make a change in a sibling package you would yarn to propagate the change.
@wclr workspace symlinks/hoisting aren't great because often times multiple versions of a library can't coexist together. For example I have a monorepo package that has React as a dev dependency but Yarn workspace will symlink along the node_modules folder too when I use the package elsewhere and that causes all kinds of problems.
Although issue is resolved, i would just like to add to @robgraeber comment. I'm dealing with same issue - devDependencies. This is really painful in yarn workspaces. Ideally, yes, you would sync dependencies, however that is not feasible in big monorepos that may contain multiple packages and projects.