[Question] Can I use yalc in a "permanent" manner within a monorepo? about yalc HOT 9 CLOSED

@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.

from yalc.

@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.

from yalc.

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.

from yalc.

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. 😅

from yalc.

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.

from yalc.

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.

from yalc.

@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 ™️

from yalc.

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.

from yalc.

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.

from yalc.