-
Notifications
You must be signed in to change notification settings - Fork 3
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
Configurational dependencies #8
base: main
Are you sure you want to change the base?
Changes from 5 commits
193a856
7a4335b
008138c
73eaab8
9ac01dc
0114c3d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,59 @@ | ||
# Configurational dependencies | ||
|
||
## Summary | ||
|
||
A new type of dependencies for installing configuration and hooks. | ||
|
||
## Motivation | ||
|
||
We want to make it possible to share some configurations between projects. Storing the configuration in regular dependencies is not an option as we might need the configuration during installation of the "regular" dependencies ("dependencies", "devDependencies", and "optionalDependencies"). Hence, we need to install these configurational dependencies before other types of dependencies. | ||
|
||
Some examples of usage: | ||
|
||
* Installing hooks used by [`.pnpmfile.cjs`](https://pnpm.io/pnpmfile). | ||
* Installing the list of dependencies that are allowed to be built (the [pnpm.onlyBuiltDependenciesFile](https://pnpm.io/package_json#pnpmonlybuiltdependenciesfile)). | ||
* Installing [catalogs](https://pnpm.io/catalogs). | ||
* Loading patch file. | ||
|
||
## Detailed Explanation | ||
|
||
There will be a new field in `package.json` called `pnpm.configDependencies`. For example: | ||
|
||
```json | ||
{ | ||
"name": "my-pkg", | ||
"version": "0.0.0", | ||
"pnpm": { | ||
"configDependencies": { | ||
"my-configs": "1.0.0+sha512-30iZtAPgz+LTIYoeivqYo853f02jBYSd5uGnGpkFV0M3xOt9aN73erkgYAmZU43x4VfqcnLxW9Kpg3R5LC4YYw==" | ||
} | ||
} | ||
} | ||
``` | ||
|
||
These new type of "configurational" dependencies will be npm packages with a lot of limitations: | ||
|
||
* They won't have any dependencies. Even if they will have dependencies, pnpm will ignore them during installation. | ||
* They will not have lifecycle scripts. | ||
* They will only be installable via exact versions. | ||
|
||
These dependencies will be installed into a new directory (name to be decided), not into `node_modules`. | ||
|
||
## Rationale and Alternatives | ||
|
||
The `"onlyBuiltDependencies"` list can currently be loaded from `node_modules`. However, this introduces "works on my machine" issues since the list isn't available during the link-from-store stage. As a result, if the dependency is not allowed to be built, it might still be loaded from the side-effects cache. | ||
|
||
## Implementation | ||
|
||
These dependencies will be installed as early as possible in order to be able to load settings from it. So this should happen ouside of the `@pnpm/core` module. When we call `mutateModules` we should already have all the configurations from `pnpm.configDependencies` loaded and ready. | ||
|
||
## Prior Art | ||
|
||
Comment on lines
+50
to
+51
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this similar to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe this is different than This RFC is similar what templates was trying to do with reusable configuration, but only for pnpm specific settings. Similar to templates, configuration is stored in the package manifest since that's available at earlier stages of the installation process. However, I think it's a lot simpler than templates and likely to be less controversial since it's only for pnpm related settings and not existing |
||
There was a big RFC by Brandon Cheng about a much more powerful system using [templates](https://github.com/pnpm/rfcs/pull/3), which was rejected. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The new system here targeting just pnpm specific settings is a lot easier to understand. 🙂 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TBH, I don't remember why exactly it was rejected. |
||
|
||
## Unresolved Questions and Bikeshedding | ||
|
||
{{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} | ||
|
||
{{THIS SECTION SHOULD BE REMOVED BEFORE RATIFICATION}} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, using node_modules could have advantages but would also require additional changes in the existing installation code. Unless, we use a dot directory inside node_modules, like
node_modules/.pnpm-config
. Ornode_modules/.pnpm/config
. This way users wouldn't have to add new entries to.gitignore
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like the idea of
node_modules/.pnpm-config
as an analogue to the existingnode_modules/.pnpm
dir. I feel like that makes it clearer that these are NPM packages, but live under a namespace isolated from the existing packages innode_modules/.pnpm
.