[Feature]: `yarn workspaces focus` should make all subsequent operations "focused"

[SimenB]

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

Describe the user story

Essentially https://twitter.com/VLecrubier/status/1301620546589913088.

Our current workflow when building a module/artifact on CI (with yarn v1, fwiw) is:

• a custom script that does yarn workspaces info and finds a package and its dependencies - it then runs rm -rf on all other packages and runs yarn in root (so essentially yarn workspaces focus, but will modify lockfile)
• we then use oao to run yarn build in all packages which has that command following the inverse dependency tree etc.

That last step is still needed if we were to migrate to Yarn v2 as we cannot do yarn workspaces foreach -pt run build as yarn will run that in all workspaces rather than the ones focus has... focused.

Describe the solution you'd like

After running yarn workspace focus all further yarn workspaces * commands should respect the fact we're currently "focused" and not do work on all workspaces. I'm specifically after yarn workspaces foreach run, but I think other commands like yarn why or yarn up should also only operate on the "focused" workspace and its dependencies.

As an aside, for this I think it'd make more sense if focus just "focused" without installing anything. So yarn workspaces focus foobar would just set some somewhere in .yarn/ I guess, and when we then run yarn install afterwards, only foobar (and its dependencies) would be "installed".

Describe the drawbacks of your solution

Not sure... It would probably mean more forking of logic ("all workspaces" vs "some workspaces") in multiple places, but I don't think there's any drawbacks beyond the implementation aspect of it?

Describe alternatives you've considered

Not use yarn workspaces focus at all as it doesn't work for our use cases and keep using a manual approach.

Additional context

Happy to chat on Discord about what other stuff we do on CI to build if applicable.

[andreialecu]

Just for reference: there's a plugin at https://gitlab.com/Larry1123/yarn-contrib/-/tree/master/packages/plugin-production-install that can probably handle this scenario.

It can build dependent workspaces using yarn pack in the correct order, as oao would do. So all you need to do is to define a prepack script in all workspaces with their build command, and use package.json/files or .npmignore to define what the built artifacts are.

Depending on what your actual requirements are, you may be able to use it as a better approach than using focus. I've been using it successfully in several projects and favor it greatly vs the workspace focus command, for building/deploying.

[SimenB]

Thanks for the link! I would prefer if Yarn core made the focus command more useful, but using custom plugins definitely is an option. Although unlikely one we'll pursue over sticking to Yarn v1 as the workflow we have there works pretty good.

focus might not be enough for us regardless as we run jest and eslint from the root of the repo, and since focus leaves all other files in the repo, those commands will potentially fail as not all packages will be built. So we'll probably keep using our script which does rm -rf. That's a thing that's weird about our setup tho, and could be worked around by us asking yarn "what workspaces are installed" and provide a filter based on that.

Anyways, digressing 🙂

[arcanis]

The problem with improving focus is that:

• it would significantly expand its scope in a way that's not fully explored yet (by that I mean that we usually try to provide one blessed way to solve a story, but focused workspaces are often part of many slightly different stories depending on the projects they are used with)

• we wouldn't dogfood it (or at least neither the Yarn repo nor my own ones would), and thus it would be more difficult to maintain it (also in terms of code reviews, especially compounded with the "many slightly different stories" I mentioned).

So all in all I'd prefer to see this live in a contrib plugin (such as @Larry1123's one), and only moved into our org once a consistent workflow has been refined.

(Regarding yarn workspaces foreach in particular, cf the new -R,--recursive flag which is likely what you need)

[andreialecu]

My 2 cents, since this is also an use-case I've been interested in. I think the best "catch-all" solution here would be to have a parameter to the focus command:

• A path in which to create a complete copy of the focused project.

I vaguely remember suggesting this before in some other issue but I can't find it.

yarn workspaces focus --outDir /some/new/path would copy the focused workspace and all dependencies to the given path. This can easily be implemented as a plugin as well though.

[SimenB]

Fair enough! In that case I'd argue that focus should be renamed to focus-install or something - it's only purpose is installation, it's not really a generic "focus" on a workspace at all. The docs state this, but I think being more precise with the name of the command itself better communicates what it does (and, more importantly, what it doesn't do).

Or possibly split up into more subcommands? So just yarn workspaces focus foobar is an error, the user should do yarn workspaces focus foobar install. That way a separate plugin could hook into it and expose more commands than install - such as run etc. Not sure, very half baked idea.

[andreialecu]

@SimenB it seems that your request already works, but it's not yet released and you need to install the plugin from sources.

yarn plugin import from sources plugin-workspace-tools
cd packages/my-workspace && yarn workspaces focus && yarn workspaces foreach -Rt run build

build will only run on my-workspace and its workspace dependencies, in topological order.