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.

Sign up for GitHub

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

Observations on npm's behavior #11

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Observations on npm's behavior #11

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5324ce5
Observations on npm's behavior
rotu Aug 22, 2024
93a3116
package name ambiguity for npm view, npm docs
rotu Aug 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions research/name.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,13 @@ Analysis of the `name` property
- `npm config set <Scope>:registry <Registry URL>` or `npm login --registry=<Registry URL> --scope=<Scope>` (`<Scope>` must include the `@` symbol).
- One scope must only ever point to one registry.
- One registry can host multiple scopes.
- Observations from [email protected]:
- `npm install` installs dependencies listed in the current `package.json`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am guessing this is a WIP? Sorry if this is too early of a comment, but I think we should avoid documenting too many specific behaviors. The goal would likely be to call out specifically any unexpected behaviors around the name field specifically but not much else. Does that make sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good feedback. yes, a little early, and my additions in this PR definitely need organizing and elaboration.

I think the behavior shows that the description of the name field in npm is (understandably) assuming you are only thinking of package.json describing a package being added to or installed from a registry. At runtime, when package.json is in a module in your node_modules folder, the name field is essentially unused.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

… except when it's got an exports field and is self-referencing - then it's quite used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljharb True! I don’t understand how widespread self-import is. (I didn’t even know it was a special case instead of just node_modules resolution until a day ago or so!) Do you know if there are any stats?

I personally have been using relative URL imports inside a package so as not to repeat the package name everywhere and so I can run my code in a browser without transpilation/bundling.

- `npm install ./some/folder` will fail if `some/folder/package.json` is missing a `name`.
- `npm install alias@./some/folder` can install even if `./some/folder/package.json` does not exist.
- `npm install alias@./some/folder --install-links` can install even if `./some/folder/package.json` does not have a `name` nor `version`.
- `npm publish` and `npm pack` require both `name` and `version`.
- `npm view` and `npm docs`, when run inside a directory with a `package.json`, show information about the latest published version of the package with matching name on `npm` (even if unrelated). This suggests that even unpublished packages should have globally unique names (e.g. by using a scoped name).

## Sources

Expand Down