Yarn 2: support focusing on a workspace for monorepo

[osdiab]

Is your enhancement request related to a problem? Please describe.
My project uses yarn workspaces with a monorepo, and we use Heroku to deploy our API. But just running yarn install means that it ends up installing all the dependencies of our monorepo, which wastes time especially for tools that require building during the link step.

Describe the solution you'd like
I'd like a way to configure to install using yarn workspaces focus $MY_PACKAGE_NAME to skip installing deps for all the other packages, as they're irrelevant for my Heroku app deploy

[jamesopti]

This ☝️

Is there no way to do this with Heroku currently? I came across this thread in search of a way to override the yarn install command to be yarn workspaces focus server.

[osdiab]

Probably wouldn't be hard to implement though, with an environment variable. Maybe YARN2_FOCUS_WORKSPACE? (if it starts with YARN_ then the yarn tool will explode)

[ostenbom]

We've fixed this in our fork like this. Two reasons I don't open an upstream PR (yet):

• On workspaces focus there is no --immutable flag. One could check for a yarn.lock change after install, but what's the expeced behaviour here really?
• Pruning dev-dependencies doesn't always make sense in this use case. We're skipping it here for example because it takes longer to remove all deps and install again (the default otherwise), and doesn't add significant weight to our slugs. Should this be toggleable?

With clear answers to those two a PR might be closer to reality!

[tevonsb]

One more thing to note here:

This feature is doubly important if you want to slugignore other parts of a monorepo (which I do). In this case yarn will fail because once part of the workspaces tree is ignored the lock file would be modified.

Maybe this answer 1) from the comment above. I think the expected behavior of workspaces focus is to modify the lockfile and any additional checks with be left to the developer. Not ideal but better than having a massive slug and a headache deploying monorepos

[thlmenezes]

Any updates here, I've stumbled upon this problem this week.

I believe this also partially solves the problem described in #906

My initial though to solve this was to skip pruning and execute focus on post-build script

[tevonsb]

Yea, I skipped pruning (don't have focus in post-build). My slug is a lot larger now, but it works.

[thlmenezes]

@tevonsb how did you manage to skip pruning using yarn 2: did you use the custom buildpack by mentimeter devs mentioned above or a config using this buildpack by heroku?

[tevonsb]

It was my slug-ignore that was causing the issues!

It was removing a sub-repo which contained dependencies, so yarn was getting confused and trying to reinstall them when it ran.

[JakeSidSmith]

Thanks for the fork @ostenbom, works a treat. 😁

I was able to achieve a specific workspace install and build using a fork of https://github.com/mentimeter/heroku-buildpack-nodejs - I just updated from upstream: https://github.com/loggedltd/heroku-buildpack-nodejs

And a new buildpack I've whipped up to add the node version, build and start scripts to the root package.json from the workspace you want to build/run: https://github.com/loggedltd/heroku-buildpack-yarn-workspace

Would love to combine the 2, but don't have the time at the mo.

Note: heroku-buildpack-yarn-workspace must run before heroku-buildpack-nodejs