Yalc recursive

[Warrick FitzGerald]

I've created an example application here: https://github.com/WarrickFitz/yalc-recursive

master1 includes package-a, which in turn uses package-b

git clone [e-mail]:WarrickFitz/yalc-recursive.git
cd yalc-recursive
cd master1
npm install
npm run build

webpack looks at .yalc/package-a/package.json and finds "file:.yalc/package-b" .. which is not installed in the "master1" project ... so it fails.

I can add package-b to the master1 application but that corrupts my setup.

Is there some way to make this setup work \ simple?

[Stephen Wicklund]

I similar thread was created here btw: #16

There is a way to accomplish this, but only if you modify yalc to allow re-inclusion of the .yalc folder in its local publishes.

In fact, that is exactly the main reason I made this "wrapper" around yalc: https://github.com/Venryx/zalc

It lets you add an entry to .yalcignore that "re-includes" the .yalc folder in local publishes, letting the recursive yalc-add approach work. (see its readme for more info)

You can see an example of it in use for this "middle dependency" here: https://github.com/Venryx/web-vcore

Note that while this approach works, it is "fragile".

Some rules I follow:

1. Make sure the version of your subdep that you are yalc-linking is compatible with the version of that subdep specified in your package.json. (else npm/yarn will install from the registry rather than the .yalc folder)
2. To actually tell npm/yarn to "symlink" from "node_modules/X" to ".yalc/X", the best way imo is to have this in your package.json, in both your root project and the shallow/middle dependency:

	"workspaces": [
		".yalc/*"
	],

I'm not sure if it is necessary, but it at least makes things easier. (it's like telling npm/yarn to have all the packages in that folder symlinked, rather than hard-coding such link:.yalc/X entries in your package.json, ruining the regular install process for people who don't want the symlinked versions)
3) Make sure that the entries in yalc.lock are of the form:

    "XXX": {
      "signature": "XXX",
      "pure": true
    },

If you use the other linking types, then things can get messed up (I forget exactly how, but I think the main annoyance was that it hard-coded the link:.yalc/X entries into package.json, whereas I wanted it to be "local only"). Anyway, to create such entries, I think you can use yalc add XXX --pure. (though I've been adding the entries manually, so don't know for sure)
4) Make sure you run npm install/yarn after you add a yalc-linked subdep, to cause it to create the actual symlink. (fwir, yalc add XXX --pure was not enough, at least in some cases.

In conclusion: This is currently the only way I know to get what I want in terms of "semi-automated, recursive dependency linkage", but it is still pretty fragile, because there are several rules you have to follow to make it all work. It would be nice if yalc could be expanded with a new command/strategy, that handles this recursive-yalc-linkages case without requiring my zalc wrapper, as well as all these rules. (I'm not sure if all four of these rules are necessary, but most of them are atm)

EDIT(2024-04-22): I am not satisfied with the approach above anymore, because it causes "churn" in yarn.lock between devs, if they have differing deps/subdeps connected using yalc. So I am now trying to rework my "zalc" program to not be based on yalc anymore, instead offering a streamlined path for just the functionality I need, with the main functionality being to modify the "resolutions" section for yarn to use rather than messing with the "dependencies" section. (with zalc up and zalc down as basically the only commands needed in the consumer project, and zalc public/push as the only ones needed in the dep/subdep project)

[CodeOfLight]

Thank you sir!

This is SO incredibly helpful, I can't believe it.

For those interested I've added a "zelc" branch to my repo and followed the above instructions ... works like a charm.

https://github.com/WarrickFitz/yalc-recursive/tree/zalc

Thank you again for your reply and your work on this @Venryx