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

Excluding the root from recursive exec (and other workspace commands) #2769

Closed
mshick opened this issue Aug 13, 2020 · 7 comments · Fixed by #3647
Closed

Excluding the root from recursive exec (and other workspace commands) #2769

mshick opened this issue Aug 13, 2020 · 7 comments · Fixed by #3647
Labels
area: monorepo Everything related to the pnpm workspace feature type: feature
Milestone

Comments

@mshick
Copy link

mshick commented Aug 13, 2020

Coming from yarn, I've been puzzled by the behavior of treating the root package.json and scripts like another workspace in a monorepo. I found the PR where the behavior was changed to always include it, but there doesn't seem to be any opt-out on that, even though I see it has been made optional (opts.includeRoot) in the code.

In this case, I'm running pnpm recursive exec and don't want it running on root. I can't figure out how to exclude it though. Not sure if this is a feature request, or a request for help.

@zkochan
Copy link
Member

zkochan commented Aug 13, 2020

PR where the behavior was changed to always include it

that PR did not change how the commands work. It just allowed to omit adding '.' to the globs in the pnpm-workspace.yaml file. Obviously, the root package should always be part of the workspace.

If you have all your projects in a subdirectory, you can do something like pnpm --filter ./packages exec

@michens
Copy link
Member

michens commented Oct 7, 2020

I have to agree with @mshick that this is surprising behavior since lerna also doesn't work this way.

When I tried converting a repo from using lerna, I basically replaced lerna run with pnpm -r run and immediately hit an infinite loop as the root of the repo contained scripts for our CI machines which come with NPM, but not pnpm and contained something like the following:

"scripts": {
    "build": "npx lerna run build"
}

It's easy enough to add explicit filters for all the scripts blocks throughout the repo that had used lerna commands, but if I ever forget to manually add a filter when running at the command line, I'm likely to encounter issues if the root has a command with the same name.

The package finding code already supports an option to ignore the root, so it should be straightforward to enable setting that option in the workspace yaml.

Would you accept a PR?

@TranquilMarmot
Copy link

We've also run into this when trying to add new packages, i.e.

pnpm add --recursive axios

I would expect this to only install it in the sub-projects, but it also installs in the root package.json.

I think this is especially surprising with pnpm add since the --ignore-workspace-root-check is usually needed to install packages to the root workspace. It almost seems like with pnpm add, it should only add packages to the root if you pass that flag.

@zkochan
Copy link
Member

zkochan commented May 11, 2021

This would be a breaking change but adding an option for now sounds good to me.

@zkochan zkochan added area: monorepo Everything related to the pnpm workspace feature type: feature labels May 11, 2021
@pastelsky
Copy link

Wanted to pitch in to say that in most cases, not having the command execute on the top level is what most people would want. Also, adding a filter for something that seems like should be the default (coming from bolt / yarn / lerna) doesn't feel right.

@zkochan
Copy link
Member

zkochan commented Aug 6, 2021

PR: #3647

@zkochan
Copy link
Member

zkochan commented Aug 6, 2021

https://github.com/pnpm/pnpm/releases/tag/v6.12.0-2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: monorepo Everything related to the pnpm workspace feature type: feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants