Share dependencies among workspaces?

[cakoose]

I have a project with a few workspace, "frontend", "backend", "common". Each has its own "package.json" and dependencies.

With Yarn 1, I put the "typescript", "eslint", and "jest" dependencies in the top-level "package.json". Seemed like an easy way to ensure the same version of those tools was used across all three workspaces.

With Yarn 2, this doesn't seem to work the same way. For one, the "tsc" command (from TypeScript) is not available in the "backend" folder anymore.

One solution is to put the "typescript", "eslint", and "jest" dependencies into each of the workspace "package.json" files. Is there another way to share dependencies between workspaces?

[arcanis]

How to share scripts between workspaces?

[cakoose]

Oh, thanks, that works pretty well. One issue is that it adds an extra "yarn" invocation, which makes things noticeably slower.

Coming from Yarn 1, the startup delay on tsc is going from 0.46s to 1.6s.

• With Yarn 1:
  • ./node_modules/.bin/tsc takes about 0.17s.
  • yarn run tsc --version takes about 0.46s.
• With Yarn 2 (nodeLinker: node-modules):
  • yarn run tsc --version takes about 0.9s.
  • yarn run my-cmd (which just runs yarn run g:tsc --version) takes about 1.6s.
• With Yarn 2 (PnP):
  • yarn run tsc --version takes about 1.2s.
  • yarn run my-cmd takes takes about 2.1s.

Is there a way to avoid the extra "yarn" invocation?

[arcanis]

Nope. However the yarn run perfs got significantly improved in 3.0.0-rc.2, especially if your project is medium-large.

[cakoose]

The Yarn 2 numbers above are from 3.0.0-rc.2. My project isn't that big. Maybe I'll just copy the dependencies into each workspace for now.

[merceyz]

You can also use yarn run -T <bin name> to use the binary from the project root

[Knagis]

yarn run -T seems to only accept scripts, not binaries.

[rachelslurs]

@arcanis how does this work with dependencies needed to run tests within packages? ie:

my root package.json has enzyme, redux-mock-store, etc.
my package src/packages/packageA does not. how can i potentially tell it to resolve packages using the root as a fallback?

many thanks in advance!

[rachelslurs]

I think the answer is to add them as dependencies at the root. 🤔

[arcanis]

In theory the best is to not rely on fallback. Each project that would require it would list those as dependencies.

Popular alternatives are to use aliases in your test framework (using require.resolve to pre-resolve those dependencies relative to your configuration file, letting you access them from anywhere), or to add them at the root.

[eliw00d]

I use the same setup and have this working using this: https://yarnpkg.com/getting-started/qa#how-to-share-scripts-between-workspaces

In each package.json where you have a dependency, typescript for example, that needs to be used in child worktrees/workspaces, just add a g: script. Then the build script in a child workspace can just use yarn g:tsc for typescript or whatever other tools you use.

Also, I use yarn workspaces focus root backend service or yarn workspaces focus root frontend application for docker to install dependencies in root, backend, and service or root, frontend, and application. That way, I can have common build tools in the root, like typescript, and backend or frontend specific build tools in their respective folders, and finally service or application specific dependencies in their respective folders. Works great!

[alamothe]

I am fine with listing dependencies in each package that uses them, but how can I share the same version? I'd like to be able to bump a version for all packages that use it simultaneously.

[Nirmit04]

Hi @darrikonn ,
I have the same use case, We have some dependencies that aren't script-related like lodash, axios, etc which are used by multiple workspaces, were you able to resolve this?

[darrikonn]

Yeah, in the root's package.json I declare the dependency versions; and in the workspace's package.json I declare the dependency with the "*" version.

[Nirmit04]

I am using yarn 2.4.0 and this doesn't seem to work for me, I have multiple react applications, did you change anything in your webpack config or any o ther config file?

[darrikonn]

I'm running on 4.0.0-rc.44

# cat .yarnrc.yml
nodeLinker: node-modules

yarnPath: .yarn/releases/yarn-4.0.0-rc.44.cjs

[Nirmit04]

thanks

[alexeymatveevp]

I'm struggling with this "shared dependencies" problem as well - imagine having 7 sub-projects and updating "typescript", "webpack", ... in all 7 simultaneously - very painful
I would like the same mechanism as in maven dependency management that was invented like 20 years ago
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
You have parent project and you can specify all versions there. In child projects - specify dependency name only
Would be very nice if new yarn 2 could support this

[VRuzhentsov]

I found a solution in stackoverflow
to set TS version in the root package.json
and in all child packages to set "typescript": "*"

[artyil]

Have exact same issues migrating from yarn v1 to berry. Referring @davidluckystar comment, locking common dependencies for multiple packages / workspaces in one place without need of redeclare them per package was a great feature. Why there is no official docs refers it in berry?

[milesj]

What's stopping y'all from just running these commands in the root? Or defining the package scripts there?

[artyil]

@milesj - I tried it, some of the scripts still produce unexpected results so it won't work out of the box for migration of existing projects / monorepos.

It would be nice to have official migration steps to handle this one. Feels like a breaking change and migration should provide enough information or recommended solution to minimize side effects. Maybe I missed something, if anyone can share a link please do (find this discussion wasn't easy)

running these commands in the root? defining the package scripts there?

• simplicity define top level dependencies in one place must be supported in monorepo
• scalability consider 20 packages in monorepo, won't scale (to me) to handle all scripts in single root file
• separation of concerns I would like to isolate many scripts per package, there are enough existing use cases (noted in comments above)

What was wrong with existing approach? I want to be able to control commons packages in one place and define execute scripts per package when I need to. Any explanations or links highly appreciated 👍

[milesj]

I don't disagree. Root deps are typical dev tools, so having them available everywhere would be nice.

At work we just run everything from the root, as ESLint, TypeScript, Jest, etc, all work better in that pattern.

[Knagis]

When in doubt, write a plugin. That has been my principle recently for yarn..

For this particular topic, i did end up writing a plugin that will run the binary from the root in the context of the package the command was executed. The nice thing is that i don't need custom names, the same yarn eslint or yarn tsc would work exactly as with direct dependencies.

I don't use PnP, so the plugin just reads the node_modules package.json but that should be easy to adjust.

As an added bonus, the dependencies don't even have to be installed in root, they can be launched from some other folder as well. We use this to dynamically change which version of storybook we use when running the same yarn build-storybook command in different packages.

// @ts-check
/* eslint-disable import/no-unresolved, @typescript-eslint/explicit-member-accessibility */

/*
Plugin that automatically runs selected binaries from the root, even
when running inside of an individual package. This is so that such
packages don't have to be added as depenendencies everywhere.
*/

const npmBinsToPackageName = {
    "cross-env": "cross-env",
    "jest": "jest-cli",
    "stylelint": "stylelint",
    "ts-node": "ts-node",
    "eslint": "eslint",
    "gherkin-lint-ts": "gherkin-lint-ts",
    "webpack": "webpack",
    "tsc": "typescript",
    "build-storybook": "../build/webpack/storybook6_5/node_modules/@storybook/react",
    "start-storybook": "../build/webpack/storybook6_5/node_modules/@storybook/react",
};

const nodeFlags = {
    "build-storybook": ["--max-old-space-size=16384"],
    "start-storybook": ["--max-old-space-size=16384"],
}

const paths = [];
for (const k of Object.keys(npmBinsToPackageName)) {
    paths.push([k], ["run", k]);
}

module.exports = {
    name: `plugin-root-bin`,
    factory: require => {
        const { BaseCommand } = require("@yarnpkg/cli");
        const { Option } = require("clipanion");

        class ExecuteBinFromRootCommand extends BaseCommand {
            static paths = paths;

            args = Option.Proxy();

            async execute() {
                const fs = require("fs");
                const path = require("path");

                const ownPackageJson = JSON.parse(await fs.promises.readFile("package.json", "utf-8"));
                let cmd = this.path[this.path.length - 1];

                if (ownPackageJson.scripts?.[cmd]) {
                    throw new Error(`'${cmd}' is defined in package.json but the 'plugin-root-bin' also defined it. To avoid unexpected results, please rename the script in package.json`);
                }

                const dir = await this.getBinaryPackageDirectory(fs, path, cmd, ownPackageJson);
                const pkg = JSON.parse(await fs.promises.readFile(path.join(dir, "package.json"), "utf-8"));

                const packageRelativeBinPath = typeof pkg.bin === "object"
                    ? pkg.bin[cmd]
                    : pkg.bin;

                const binPath = path.join(dir, packageRelativeBinPath);

                process.exitCode = await this.cli.run(["node", ...(nodeFlags[cmd] || []), binPath, ...this.args]);

                // seems something in yarn resets the exit code, so force exit
                process.exit();
            }

            async getBinaryPackageDirectory(fs, path, cmd, ownPackageJson) {
                return path.resolve(__dirname, "../../node_modules", npmBinsToPackageName[cmd]);
            }
        }

        return {
            commands: [
                ExecuteBinFromRootCommand,
            ],
        };
    },
};