Is there a way to have default install filter of {.}...
?
#7226
Unanswered
alex-statsig
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a monorepo setup with several apps (ex. console, intern, etc.) and several library folders (lib/node/entity, lib/shared/core, lib/shared/graphql-types, etc.). My goal is to make it easy to install the packages (including dependencies) for one folder only. This means people can run install in an app and the relevant libs get installed (but no other apps). Also ideally from the root, they can run install to install all apps (helpful when updating lockfile for some package; ex. I've seen people ).
Originally, our setup started with disabling
recursive-install
, since that leads to installing the whole workspace, which is overkill (for local dev and CI/CD, especially if consistency is desired). Then later we added a dependency from the root package.json to each of our apps, to allow for a quick install of every app. However, it seems like with that setup, runningpnpm install
in a folder like/console
actually leads to installing/
as well, which has a dependency on/intern
(a different app).Next we removed the dependencies from our root package.json (since those lead to installing all apps all the time), and re-enabled recursive install. We then updated our CI/CD to filter using
--filter {.}...
to mimick the old behavior best. However, this is annoying for developers to type out locally, and most will just runpnpm i
. Thus I'm wondering if there's a way to make the default behave like that, with a filter of{.}...
or perhaps{./**}...
(to include nested folders, such as running from the root).I think the setup we've landed on is probably the best middle-ground, the only downside being our CI needs to specify
--filter {.}...
all the time, and local development doesnt mirror CI/CD as well (which it never will perfectly, but more common for devs to install in the wrong app and not realize)I found similar discussion at https://github.com/orgs/pnpm/discussions/3615, but it doesn't seem to fully discuss these points
Beta Was this translation helpful? Give feedback.
All reactions