[Feature] Self-contained runtime from workspaces package

• I’d be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

I want one command to create a zip file with the code from a workspaces package and all its dependencies.

The primary reason for me, is deploying to AWS Lambda. But this feature is useful to anyone who wants to compile part of their monorepo and discard the rest. For example deploying into a container.

Describe the solution you’d like

I’m not sure how to implement this, though I can easily see this being served by a plugin if they are capable of this.

A command such as yarn bundle which takes and argument of the local package to bundle, or if possible can work it out from the directory you’re in.

I’m not concerned about the name, its just the one that kept popping into my head.

Then likely following the pnp setting of the workspace, the required dependencies would be compiled and placed in a temporary folder with the contents of the package (such that they are usuable).

That temporary folder would then be zipped, and saved to a location defined either in package.json or but an argument passed in by the user.

We would also need the ability to exclude files or folders.

yarn bundle --out .dist/bundle.zip --exclude .dist

Describe the drawbacks of your solution

I think this is a mostly best practice approach to this type of bundling, but it may be more opinionated than I’m aware of.

This is not a feature that would be useful for those developing packages that are published. That use-case is already well covered, this serves a different purpose.

I think things like postinstall would not work, unless you ran yarn install upon opening the package, which I think would defeat the purpose of this. It should be a zero-install, unzip and run situation. I don’t think postinstall should run though, given the target outcome.

Describe alternatives you’ve considered

In the past, I’ve used hacky approaches with yarn and npm, that keeps node_modules next to the source. The whole package is then zipped up.

This no longer works with pnp.

Yarn already has yarn pack, this would be similar, but for the use-case of deploying, not publishing.

Additional context

This may not fit exactly into the world of a package manager, but I think it does fit into the world that Yarn is heading too.

There’s some existing tickets (#489 and #859) that I think touch on the same issue, and similar solution.

[ojkelly]

Just to finish off this ticket, I’ve found some time to write up some documentation on this plugin. And make a site with a bit more information.

Theres some still to do things in the issues queue, but as it is, it’s ready to start being used and tested.

Here’s a guide on how to use it owenkelly.com.au/posts/2020/yarn-build

And here’s a link to the plugin’s site yarn.build

[ojkelly]

@lmcarreiro the example packages in the repo I linked above are all private: true, and they all depend on each other. I think your problem in #1200 may be solved by the build command I added, but not by the bundle command.

The build command looks for all the local packages and works out a DAG by recursing down each package and finding any dependencies that are also local. After that it creates a build queue, and runs the build script in package.json in each package.

The bundle command depends on build having already been run (which is why I wrote the build command). It then copies just whats needed to a temporary directory and runs yarn install.

So, where yarn itself is perfect for managing external dependencies, build is for local dependencies and bundle is for deployment.

I’m working on much more detailed documentation and configurability.

---

1. Docker Yarn is pretty good with pnp in not needing to make changes to your deps, so unless you update them that part shouldn’t need to change.

I haven’t thought a lot about yarn bundle with docker yet, my need is specific to aws lambda right now. However, I’ve used plenty of containers in the past and it largely looks like another deploy target.

I think theres a bunch of configuration to add to yarn bundle to suit different deployment targets.

For docker, if your dependencies are all in .yarn then all thats likely to change is whats in packages.

1. post-install - in the build and bundle command neither call post-install and I dont think they should (though if theres a reason for it, it could be done) because thats already taken care of by yarn install.

yarn bundle run on windows would most certainly break on linux (if there were os specific deps). But I don’t think thats an issue, in that I would strongly suggest yarn bundle should only be used in production as part of a CI/CD pipeline. Building on your machine, then deploying is too unreliable for production usage.

---

I think your use case may be solved by bundle but with some additional work to properly support docker.

If not, I think this is where yarn’s plugin model really suits. In that we can have both plugins targeted at slightly different problems.