Git Product home page Git Product logo

validate-npm-package-name's Introduction

validate-npm-package-name

Give me a string and I'll tell you if it's a valid npm package name.

This package exports a single synchronous function that takes a string as input and returns an object with two properties:

  • validForNewPackages :: Boolean
  • validForOldPackages :: Boolean

Contents

Naming Rules

Below is a list of rules that valid npm package name should conform to.

  • package name length should be greater than zero
  • all the characters in the package name must be lowercase i.e., no uppercase or mixed case names are allowed
  • package name can consist of hyphens
  • package name must not contain any non-url-safe characters (since name ends up being part of a URL)
  • package name should not start with . or _
  • package name should not contain any spaces
  • package name should not contain any of the following characters: ~)('!*
  • package name cannot be the same as a node.js/io.js core module nor a reserved/blacklisted name. For example, the following names are invalid:
    • http
    • stream
    • node_modules
    • favicon.ico
  • package name length cannot exceed 214

Examples

Valid Names

var validate = require("validate-npm-package-name")

validate("some-package")
validate("example.com")
validate("under_score")
validate("123numeric")
validate("@npm/thingy")
validate("@jane/foo.js")

All of the above names are valid, so you'll get this object back:

{
  validForNewPackages: true,
  validForOldPackages: true
}

Invalid Names

validate("excited!")
validate(" leading-space:and:weirdchars")

That was never a valid package name, so you get this:

{
  validForNewPackages: false,
  validForOldPackages: false,
  errors: [
    'name cannot contain leading or trailing spaces',
    'name can only contain URL-friendly characters'
  ]
}

Legacy Names

In the old days of npm, package names were wild. They could have capital letters in them. They could be really long. They could be the name of an existing module in node core.

If you give this function a package name that used to be valid, you'll see a change in the value of validForNewPackages property, and a warnings array will be present:

validate("eLaBorAtE-paCkAgE-with-mixed-case-and-more-than-214-characters-----------------------------------------------------------------------------------------------------------------------------------------------------------")

returns:

{
  validForNewPackages: false,
  validForOldPackages: true,
  warnings: [
    "name can no longer contain capital letters",
    "name can no longer contain more than 214 characters"
  ]
}

Tests

npm install
npm test

License

ISC

validate-npm-package-name's People

Contributors

ashleygwilliams avatar bcoe avatar chrisdickinson avatar dependabot[bot] avatar github-actions[bot] avatar janbritz avatar lukekarrys avatar rap2hpoutre avatar thecodrr avatar timdorr avatar tomdale avatar wraithgar avatar zeke avatar zeusdeux avatar zkat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

validate-npm-package-name's Issues

[Feature Request] Browser compatible version

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

πŸ‘‹ It would be really helpful to have a browser compatible version. Do you think there is an approach to supporting this? For example either by inserting the invalid core module names at build time (the build of this library), or shipping a separate browser version just without the core module validation?

[BUG] "download" is not an allowed word in the package name

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

validateNpmPackageName("@react-cdk/core-internal-download") returns:

{
  "validForNewPackages": true,
  "validForOldPackages": true
}

https://codesandbox.io/s/brave-engelbart-8vg1fc?file=/src/App.js

Expected Behavior

validateNpmPackageName("@react-cdk/core-internal-download") returns:

{
  "validForNewPackages": false,
  "validForOldPackages": true
}

Steps To Reproduce

  1. Create this package
{
  "name": "@react-cdk/core-internal-download",
  "private": false,
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "publishConfig": {
    "access": "public"
  },
  "author": "",
  "license": "ISC"
}
  1. try to publish it

npm ERR! 400 Bad Request - PUT https://registry.npmjs.org/@react-cdk%2fcore-internal-download - Bad Request

  1. Change the name, it works https://www.npmjs.com/package/@react-cdk/internal-lab

The 400 error code is confusing, could we get a clearer error message? Also, https://docs.npmjs.com/package-name-guidelines is not giving tips on what's going on. The issue seems to be with the word: download.

Environment

  • npm: 8.11.0
  • Node: v16.16.0
  • OS: macOS 12
  • platform: Macbook Pro

[BUG] alias support

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

this package name is reported invalid:

mysm@npm:semver

Expected Behavior

The expected behavior is that this tool agrees with npm as to which packages are valid. npm installs mysm@npm:semver just fine.

Steps To Reproduce

e.g. by running the below two lines in a node repl:

var validate = require('validate-npm-package-name')
validate('mysm@npm:semver')

it returns:

{
  validForNewPackages: false,
  validForOldPackages: false,
  errors: [ 'name can only contain URL-friendly characters' ]
}

Environment

  • npm: 9.5.1
  • Node: 18.16.0
  • OS: ubuntu
  • platform: laptop
$ node -p "JSON.stringify($(npm --versions))" | jq "{npm: .npm, node: .node, os: \"$(uname -a)\" }"
{
  "npm": "9.5.1",
  "node": "18.16.0",
  "os": "Linux z 5.19.0-43-generic #44~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon May 22 13:39:36 UTC 2 x86_64 x86_64 x86_64 GNU/Linux"
}

changelog

it'd be cool if we wrote a changelog for this :) would be happy to help

[BUG] TypeError: builtins is not a function

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

I have an error on my github actions when trying to publish a package to NPM. I could not found any information about this, so I post the question here. If it shouldn't, please let me know.

The error is:

37 verbose stack TypeError: builtins is not a function
37 verbose stack     at validate (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/node_modules/npm-registry-fetch/node_modules/validate-npm-package-name/lib/index.js:55:3)
37 verbose stack     at Result.setName (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/node_modules/npm-registry-fetch/node_modules/npm-package-arg/lib/npa.js:127:17)
37 verbose stack     at new Result (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/node_modules/npm-registry-fetch/node_modules/npm-package-arg/lib/npa.js:119:10)
37 verbose stack     at Function.resolve (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/node_modules/npm-registry-fetch/node_modules/npm-package-arg/lib/npa.js:56:15)
37 verbose stack     at npa (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/node_modules/npm-registry-fetch/node_modules/npm-package-arg/lib/npa.js:26:18)
37 verbose stack     at Function.pickRegistry (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/node_modules/npm-registry-fetch/lib/index.js:189:10)
37 verbose stack     at Publish.exec (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/lib/commands/publish.js:107:33)
37 verbose stack     at async module.exports (/home/runner/work/typeorm-seeding/typeorm-seeding/node_modules/npm/lib/cli.js:66:5)

Expected Behavior

It should not throw any error.

Steps To Reproduce

You can go to this repo at the point of failure.

Or you can go to the action that is causing the problem.

Both places are visible, so it should be a good point to check the code.

Environment

  • npm: v8.5.3
  • Node: v16.13.0
  • OS: Ubuntu 20.04
  • platform: Github runner

Inconsistent rules between scoped and non-scoped package names

Here are examples:

Example Invalid Valid Rule/Category
1 '.pkg' '@scope/.pkg' name cannot start with a period
2 '_pkg' '@scope/_pkg' name cannot start with an underscore
3 'node_modules' '@scope/node_modules' blacklisted name
4 'favicon.ico' '@scope/favicon.ico' blacklisted name
5 'fs' '@scope/fs' core module name

Not sure if any of these are actual problems (nothing really wrong with Example 5) but I wanted to create this issue for sake of awareness and discussion.

Note that these at least seem to be consistent with logic in normalize-package-data, but I'm wondering why we duplicate this logic across multiple modules in different packages. Perhaps it would be better to centralize this logic here and add validate-npm-package-name as a dependency to normalize-package-data.

leading space redundant with url safe chars

I checked the commit history and didn't find any answers - but it seems the leading/trailing space message is unnecessary given that spaces are not url safe.

const result = validateNpmPackageName(' ')

const message = result.errors.concat(result.warnings).join('\n')

console.log(message)

// outputs
// name cannot contain leading or trailing spaces
// name can only contain URL-friendly characters

And if you're concerned with letting users know they have unexpected leading/trailing spaces in their package name, why not leave out the leading/trailing bit and just say spaces are not allowed? Leading/trailing implies that spaces in between are valid.

[BUG] Rule about spaces is already covered by rule about 'URL-friendly characters'

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

If package name contains leading or ending spaces, two errors logged when a single error would do. Rule "name can only contain URL-friendly characters" implies "name cannot contain leading or trailing spaces" so the latter is redundant.

Expected Behavior

Error "name cannot contain leading or trailing spaces" is not logged since it is redundant.

Steps To Reproduce

Run this and observe two errors in each case:

const validate = require("validate-npm-package-name");
console.log(validate(' leading-space').errors);
// Output:
// ["name cannot contain leading or trailing spaces", "name can only contain URL-friendly characters"]
console.log(validate('trailing-space ').errors);
// The same output:
// ["name cannot contain leading or trailing spaces", "name can only contain URL-friendly characters"]

Environment

  • npm: 8.0.0
  • Node: v19.6.0
  • OS: Ubuntu 22.04
  • platform: Linux

why is the maximum package name length 50 characters?

There's no rationale in the code or the commit history, and there are extant packages in the registry with names much longer than that, which is causing problems when the registry code is using validate-npm-package-name to validate new packages and returning 500 errors, e.g. npm/npm#8077 / npm/registry-frontdoor#133.

[QUESTION] Is this package still maintained?

Thank you for this useful package!

This package is widely used (587k) and have around 2 millions downloads a week πŸŽ‰. I'm not sure who is in charge of this repository now. It seems there is almost no activity by maintainers on PR and issues since 2017 (sorry if I mistake). I know some of the authors are now rustaceans 🀩and don't work for NPM anymore. Is this package still alive?

I could be one of the maintainers if you want!

[Feature Request] Simple CLI tool to validate package names

This package would be even further useful if a simple CLI was included for use in scripts.
I envision this tool as something along the following:

validate-npm-package-name "valid-name" # Returns 0, no output

validate-npm-package-name "Invalid name:here" # Returns 1
# Stderr: 
# name can no longer contain capital letters
# name can only contain URL-friendly characters

This would allow for usage in scripts, and would further the usability of this tool.
The errors given would be the exact same as those given by the 'errors' property in the Javascript API.
By default, this tool would return errors if the name is no longer acceptable, but perhaps a `--legacy`` option could be adopted to return errors only on legacy errors.
Alternatively, the tool could provide different return values depending on invalidity, (ie, if valid: 0, if legacy valid: 1, if never valid: 2).

recreating the package

hey! i have published a package and now, i'm migrating to a new account. i want to build the aforementioned package from scratch, as it was not good enough to be published. if i remove that package (the name of which is not scoped), will i be able to publish a completely new package with the same name within a short time? thanks!

Allow @version in

I'm validating anything that can go into npm install X. Does it make sense for this project to handle and ignore any "[email protected]" version suffixes, or is it expected that any consumer be responsible for stripping off this version?

Hyphen name

I guess package cannot start with hyphen as well.
At least, the name - validates successfully, but registering package with that name is impossible.

[BUG] can't resolve `module` in browser

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

We've incorporated the validate-npm-package-name package in the frontend for format validation.

Since version 5.0.1 uses Node's built-in module to validate internal packages, this configuration is undefined in the browser environment.

Furthermore, no errors are reported during the build phase, leading to a breaking change.

This might be a bug caused by the bundler not handling module correctly. Considering that validate-npm-package-name is a very low-level dependency, would it be possible to revert to the previous method?

image

Expected Behavior

should work in browser

Steps To Reproduce

codesandbox

it seems that this issue cannot be directly reproduced in CodeSandbox due to not being able to sync to the latest version.

Environment

  • npm: 10
  • Node: 20
  • OS: mac
  • platform: arm64

[BUG] bun is a core module name

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

When using the node runtime, validating the string "bun" will output:

{
  validForNewPackages: true,
  validForOldPackages: true
}

But when using the Bun runtime, validating the same string will output:

{
  validForNewPackages: false,
  validForOldPackages: true,
  warnings: [ "bun is a core module name" ],
}

Because we are checking if the name is included in the builtinModules, and in Bun, the name itself is a core module.

if (builtins.includes(name.toLowerCase())) {
	warnings.push(name + ' is a core module name')
}

Expected Behavior

The expected behaviour are the following names should be valid NPM package names:

There could be more names but I didn't check them all.

Steps To Reproduce

import validate from 'validate-npm-package-name'

console.log(validate('bun'));
console.log(validate('ws'));

Run the above code with Bun.

Environment

  • Bun: 1.1.24

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.