[BUG] `npm pkg get version` returns the correct version in inconsistent and broken formats

[vemonet]

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

When running npm pkg get version I get the version of the package returns in weird format, inconsistent, which makes it impossible to use in practice.

You can reproduce it easily here: https://github.com/sib-swiss/sparql-editor it is a monorepo with 2 packages in the packages folder

Running npm pkg get version in the root folder returns:

"0.0.0"

Running the same in the packages/sparql-editor folder returns:

{
  "@sib-swiss/sparql-editor": "0.2.5"
}

The version numbers are right, and I noticed they are just directly extracted from the version field of the local package.json. Which makes sense.

But when used in a sub folder of the workspace then npm will return a single entry JSON with the pkg name as key... It is really hard to understand why.

There are no confusion possible because there can be only one package.json in the folder, so adding this key is useless

Plus if I wanted to parse JSON I would just have parsed the package.json directly. The whole point of npm pkg get is to get the value of a key from the package.json

Expected Behavior

When running npm pkg get <key> I should get just the key value for the package of the current folder:

"0.0.0"

To be honest would even prefer without quotes, but I guess this is to keep track of the data type (in case it is an integer)

Steps To Reproduce

git clone https://github.com/sib-swiss/sparql-editor
cd sparql-editor
npm pkg get version

cd packages/sparql-editor
npm pkg get version

Code for npm pkg: https://github.com/npm/cli/blob/latest/lib/commands/pkg.js

Environment

• npm: 11.2.0
• Node.js: v23.9.0
• OS Name: macOS Sonoma 14.4.1 x86_64
• System Model Name: Macbook Pro
• npm config:

; "user" config from /Users/vemonet/.npmrc

//registry.npmjs.org/:_authToken = (protected)

; node bin location = /Users/vemonet/.nvm/versions/node/v23.9.0/bin/node
; node version = v23.9.0
; npm local prefix = /Users/vemonet/dev/expasy/sparql-editor
; npm version = 11.2.0
; cwd = /Users/vemonet/dev/expasy/sparql-editor
; HOME = /Users/vemonet
; Run `npm config ls -l` to show all defaults.

; "publishConfig" from /Users/vemonet/dev/expasy/sparql-editor/package.json
; This set of config values will be used at publish-time.

access = "public"

[milaninfy]

This is by design. When the package is a workspace package when querying for fields of that package will be result in object with workspace name and other filed values.

for your use case you can use --workspaces=false or --no-workspaces

~/workarea/rep/test-version/packages/sparql-editor $ npm pkg get version --no-workspaces
"0.2.4"
~/workarea/rep/test-version/packages/sparql-editor $ npm pkg get version                
{
  "@sib-swiss/sparql-editor": "0.2.4"
}
~/workarea/rep/test-version/packages/sparql-editor $ npm pkg get version name
{
  "@sib-swiss/sparql-editor": {
    "version": "0.2.4",
    "name": "@sib-swiss/sparql-editor"
  }
}

[vemonet]

Thanks for the clarification @milaninfy

It's quite a weird design considering the --help documentation for the npm CLI:

npm pkg get version --help
Manages your package.json

Usage:
npm pkg set <key>=<value> [<key>=<value> ...]
npm pkg get [<key> [<key> ...]]
npm pkg delete <key> [<key> ...]
npm pkg set [<array>[<index>].<key>=<value> ...]
npm pkg set [<array>[].<key>=<value> ...]
npm pkg fix

Options:
[-f|--force] [--json]
[-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]]
[--workspaces]

Run "npm help pkg" for more info

• There is no mention of --no-workspaces flag
• There is mention of a --workspaces and --workspaces <workspace-name> flags

From an reader point of view the current --help clearly indicates that I need to use the --workspaces flag to enable "workspace mode". And not that I need to explicitly says --workspaces=false

[milaninfy]

--no-workspaces is shorthand for --workspaces=false in this case.