3 ms·
One of the reasons I really like Yarn 3, is the really good support for linking local dependencies. The whole “@internal/mypackage”: “workspace:*”. That, and t
by ojkelly 5y ago
One of the reasons I really like Yarn 3, is the really good support for linking local dependencies. The whole “@internal/mypackage”: “workspace:*”.
That, and the plugin system.
Because it meant I could build on top of yarn a build/test system much like Bazel, Buck and Pants. But without the overhead of those tools.
Honestly, being able to build functionality into tooling like this is really awesome. Especially when it’s aware dependency graph.
I often have polyglot repos, with a heap of typescript, and some golang, and other stuff.
I spent a couple of weeks last year hacking away on a plugin, that can look at the whole dependency tree defined in yarn - and develop a build graph that can build everything in the required order, taking advantage of every cpu thread available. While keeping track of what’s previously been built.
From that, I extended the support to testing to do the same thing.
I wrapped it all up into a nice package and published it to:
https://yarn.build https://yarn.build
Can be installed with this command
yarn plugin import https://yarn.build/latest
Then it’s just `yarn build` which runs `package.json#scripts.build`, and `yarn test` which runs `package.json#scripts.test`.
—
Since then, there’s been plenty of development. I added a bundle command. You tell it which local package to bundle up, and it copies your repo to a temporary folder, removes everything that package doesn’t need (useful in a giant monorepo), leaves the other packages it depends on. Finally it adds a file `entrypoint.js` which sets up pnp for you, and re-exports the `main` file from your target package.
Then it zips it up for you ready for AWS Lambda (my use case), but also Docker and any other node runtime.
And recently I hacked another interesting plugin that yarn and pnp enabled. A really neat plugin that lets you write package.yaml instead of package.json.
If you replace package.json with package.yaml (or .yml), it will appear to yarn as a normal package.json. Everything works fine (with yarn, unsure about some node tooling), and you even get comments.
It’s a completely separate plugin (because it’s pretty out there), and it only has an effect if you don’t have a package.json in your package folder.
I’m using it on the golang packages in monorepo’s, because those developers are often a bit upset by seeing build tooling in a json file.
The package.yaml plugin can be installed with the following command:
yarn plugin import https://yarn.build/yaml
It’s still a bit experimental, but works pretty well.
—
It’s all open source on GitHub, if you have any issues using it feel free to post a bug report.
https://github.com/ojkelly/yarn.build https://github.com/ojkelly/yarn.build