-
-
Notifications
You must be signed in to change notification settings - Fork 941
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
Apply publishConfig for workspace packages on deployment #6693
Comments
I got the same problem, is there any solution? |
The solution we've landed on so far is to have a POST install script, that looks something like this: const writeFileSync = require('fs').writeFileSync;
const pkgJsonPath = './package.json';
const json = require(pkgJsonPath);
if (
!json.hasOwnProperty('publishConfig') ||
!json.publishConfig ||
typeof json.publishConfig !== 'object'
) {
return;
}
for (const prop of ['main', 'typings']) {
if (json.publishConfig.hasOwnProperty(prop)) {
json[prop] = json.publishConfig[prop];
}
}
writeFileSync(pkgJsonPath, JSON.stringify(json, null, 2)); Keep in mind that it needs to be adjusted for when should the script be run (probably not on every package install, but only for deployment). Also the location of |
When deploying packages, the package.json of the deployed package (as well as any other locally defined dependencies) should be treated as if it published, and mutate the package.json according to `publishConfig` and local `workspace:` dependencies. Issue: pnpm#6693
Took an attempt at implementing this: https://github.com/pnpm/pnpm/pull/6943/files Alongside the Potentially this is a breaking change because it now requires Agreed with @vteivans that the application of |
When deploying packages, the package.json of the deployed package (as well as any other locally defined dependencies) should be treated as if it published, and mutate the package.json according to `publishConfig` and local `workspace:` dependencies. Issue: pnpm#6693
When deploying packages, the package.json of the deployed package (as well as any other locally defined dependencies) should be treated as if it published, and mutate the package.json according to `publishConfig` and local `workspace:` dependencies. Issue: pnpm#6693
When deploying packages, the package.json of the deployed package (as well as any other locally defined dependencies) should be treated as if it published, and mutate the package.json according to `publishConfig` and local `workspace:` dependencies. Issue: pnpm#6693
Thank you very much @jakebailey! |
When deploying packages, the package.json of the deployed package (as well as any other locally defined dependencies) should be treated as if it published, and mutate the package.json according to `publishConfig` and local `workspace:` dependencies. close #6693 --------- Co-authored-by: Zoltan Kochan <z@kochan.io>
I don't remember how hard it was to fix all the issues that were caused by the change. But I will try to get it to v9. Created a PR again #7647 |
Describe the user story
When I run
pnpm --filter=<deployed project name> deploy <target directory>
command on an application in workspace it copies related packages from the workspace to<target directory>/node_modules
as they are. This means that thepackage.json
files in workspace packages must be in "publishable" state (e.g."main": "dist/index.js"
). This makes the packages harder to use in development mode as they must be rebuilt on any change for thedist
to represent the actual state.I would like the
package.json
to be transformed from "development" state to "publishing" state for any packages that get copied over bypnpm deploy
command.Describe the solution you'd like
As far as I understand pnpm already has a solution for this. When
pnpm pack
(or publish) is ran,publishConfig
frompackage.json
is applied. This allows for easy switching from "development" to "publishing" state. I suggest applying the same logic onpnpm deploy
- if the package that is being copied haspublishConfig
apply it duringpnpm deploy
.Describe the drawbacks of your solution
Not sure how it could break as this would be the normal package state when it's installed from a repository.
The text was updated successfully, but these errors were encountered: