Calling .version() in a monorepo reads version from the root package.json

[mkermani144]

It seems that the default behavior of version function (which reads the version from package.json is wrong for monorepos. It reads the package.json in the root of the monorepo, which is not correct.

[shadowspawn]

In simple terms, Yargs searches up through the directories looking for the nearest package.json. In detail, it is tricky even finding the starting directory for the search for all environments and layouts.

Have you got a simple reproduction, or more detail about how Yargs is integrated into a package in your monorepo and how your application is being called?

[mkermani144]

@shadowspawn
Thanks for your quick reply.

This is where we are using yargs in our monorepo:
https://github.com/rosen-bridge/utils/blob/dev/packages/cli/bin/index.ts

The cli package in the monorepo is called with npx. Essentially, running npx @rosen-bridge/cli --version prints unknown, because the root package.json in our monorepo doesn't have a version. If I add a version to it, it prints that version. Nonetheless, the package.json in cli isn't cared.

[shadowspawn]

I reproduced the problem locally in your repo. (I am not sure what happens when it gets published.)

The monorepo is using workspaces. When you run the install, yargs ends up being installed in the mode_modules folder at the root of the monorepo. When yargs looks for the nearest package.json it starts the search at its own location, which is at the root of the repo. So it finds the root package.json.

A simple work-around might be to specify the version explicitly, like .version("0.4.1"), or read it from the cli package.json yourself.

(I tried to install just yargs into the packages/cli/node_modules folder instead of the root but didn't find a way of doing that, might be possible.)

[mkermani144]

Yes, what you observed is totally normal. In other words, the whole point of this issue is suggesting a possible new solution to support monorepos.
I don't know anything of yargs implementation details, but for example, it may be a solution if it finds the nearest package.json from where it's used, other than where it's installed.

[shadowspawn]

"monorepo" only implies multiple products are being maintained from a single repository, not how they are arranged and managed within the repo. But monorepo does hint at possible problems, which may differ depending on how using npm or yarn or pnpm or lerna etc.

Labelled as an enhancement.

[shadowspawn]

Related, request to add nohoist for npm workspaces: npm/rfcs#287

[mkermani144]

Related, request to add nohoist for npm workspaces: npm/rfcs#287

Yes, many monorepo tools have this feature implemented. But nohoist, in my opinion, is an option, not a default. At least at the current time, most (or maybe all) of monorepo tools I know default to include everything in the monorepo root node_modules, unless it has a different version, etc.