Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mkermani144 opened this issue Apr 15, 2024 · 7 comments

Comments

@mkermani144
Copy link

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
Copy link
Member

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
Copy link
Author

mkermani144 commented Apr 16, 2024

@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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

"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
Copy link
Member

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

@mkermani144
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants