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

[BUG] wrong version used when publishing from a workspace #5745

Closed
2 tasks done
Badisi opened this issue Oct 25, 2022 · 8 comments
Closed
2 tasks done

[BUG] wrong version used when publishing from a workspace #5745

Badisi opened this issue Oct 25, 2022 · 8 comments
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release Release 9.x work is associated with a specific npm 9 release

Comments

@Badisi
Copy link

Badisi commented Oct 25, 2022

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

Considering the following project structure and code:

my-project
├── dist
│   └── a
│       └── package.json # { "name: "a", "version": "1.0.0" }
├── projects
│   └── a
│       └── package.json # { "name: "a", "version": "0.0.0-semantically-released" }
├── package.json # { "name: "my-project", "workspaces": [ "projects/a" ] }
└── index.js
// index.js
const { exec } = require('node:child_process');
const cmd = exec(
    `npm publish ${process.cwd()}/dist/a --dry-run`,
    { cwd: `${process.cwd()}/projects/a` }
);
cmd.stdout.pipe(process.stdout, { end: false });
cmd.stderr.pipe(process.stderr, { end: false });

Running node index.js from ./my-project will result in:

 npm notice filename: a-0.0.0-semantically-released.tgz

instead of

 npm notice filename: a-1.0.0.tgz

The issue seems to be related to the workspaces attribute from the root package.json.

Because removing this attribute will produce the proper result.

Expected Behavior

I would expect that the package.json file used during the command npm publish {path} is the one located in the given path argument and not another one from somewhere else (being cwd or whatsoever).

Steps To Reproduce

  1. git clone https://github.com/Badisi/issue-npm-publish-with-workspaces
  2. npm install
  3. npm run start

Environment

  • platform: macOS Monterey 12.5.1 (21G83)
  • node: v16.14.2
  • npm: 8.19.2 (EDIT: still exists in 10.8.2, Node 18 & 20)
@Badisi Badisi added Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release labels Oct 25, 2022
@Badisi
Copy link
Author

Badisi commented Dec 19, 2022

This issue still exists in npm@9.2.0 and, as such, label should be updated to Release 9x.
Thanks

@Badisi
Copy link
Author

Badisi commented Mar 2, 2023

This issue still exists in npm@9.6.0.

@ljharb ljharb added the Release 9.x work is associated with a specific npm 9 release label Mar 2, 2023
@Badisi
Copy link
Author

Badisi commented Jul 10, 2023

This issue still exists in npm@9.8.0.

@bweigel
Copy link

bweigel commented Oct 4, 2023

I think I ran into this problem as well, however in a slightly different manner and before opening a new issue, I will add my finding to this one.

It seems that - within a workspace - npm publish <tarball> disregards that <tarball> argument and will fall back to what it finds in the workspace:

image

This showcases the behavior inside of a workspace. Notice the lines:

npm info found workspace root at ***/cdk-constructs/dist 
...
npm verb publish   '***/cdk-constructs/dist/packages/athena'

When I move the package outside of the workspace, I get the expected outcome, where the existing tarball is used:

image

I can force the expected behavior, if I pass --workspaces false to npm publish inside of the workspace, but this is just a hack for me right now.

@npm/cli-team do you have any comment on this issue?


Edit: before anyone asks, I have also tested this with Node v20.8.0 and NPM v10.1.0 and the issue still exists.

@Badisi
Copy link
Author

Badisi commented Oct 19, 2023

I also confirm that this issue still exists in npm@10.2.0 (Node 18 & 20).

@Shakeskeyboarde
Copy link

Still an issue in npm@10.5.0 (Node 20).

@Badisi
Copy link
Author

Badisi commented Aug 15, 2024

Still an issue in npm@10.8.2 (Node 20).


I also found (like @bweigel answer) that it's no really related to the version itself but to the <package-spec> argument that is not taken into account. See #7726 for more info.

@milaninfy
Copy link
Contributor

milaninfy commented Aug 16, 2024

Closing this, as newly reported issue #7726 is the similer if not duplicate. Keeping the newer one open for better visibility.

@milaninfy milaninfy closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release Release 9.x work is associated with a specific npm 9 release
Projects
None yet
Development

No branches or pull requests

5 participants