-
Notifications
You must be signed in to change notification settings - Fork 10
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] bin
was converted to an object warnings when using string as bin
.
#83
Comments
We'll want to update the docs on this. under the hood npm was always silently converting the string to the object form, meaning the packument didn't match the package.json. We're slowly trying to remove those differences, so folks will want to use the full form going forward. |
I think users who have shortform version in thier package.json may like to preserve it because of readability - esp since documentation provided it as a alternative.
Can npm cli continue to do this without emitting warning? |
No, in the future this will not be permitted. Having a package.json file on disk that differs from the manifest in the registry is a security concern. |
@wraithgar Thanks for explanation. Just a detail: paths are starting with |
What measures exactly will you be taking? Will it be enforced by the registry (in which case is there anywhere Yarn can subscribe to be aware of similar changes)? What about packages that are already published with
Isn't this discrepancy a npm-specific thing? Why not just not make the translation, rather than deprecate "bin can be a string"? |
They will continue to be supported, and package managers will likely have to support that form indefinitely.
The enforcement will primarily be that they can't differ. See below for security caveats.
Probably yes. npm has been doing this translation a LONG time. The initial choice was to do the smallest change possible, which was to change nothing, and start warning users that the change was even happening. The next step has not been planned out, but I suspect that SOME form of bin entry validation is going to have to occur. Some of the normalization in https://github.com/npm/npm-normalize-package-bin and now https://github.com/npm/package-json is security related and will not be going away. In those cases I can see a future where the npm registry flat out refuses to accept them. That's not a near future though, as there is a pretty long tail of support for existing package managers. If you feel you have a good suggestion for where that middle ground lies: i.e. normalizing the security stuff but leaving the rest alone, we'd be very open to that. TLDR the last thing we want to do is break existing packages, and we want to give folks a LOT of time to get their package.json entries fixed in the event the registry starts enforcing more security filtering. |
Is there an existing issue for this?
Current Behavior
In the package.json's
bin
documentation, it's documented that you can use an object with one or more bin file references OR use a single string.Unfortunately, this is now marked as "error in your package.json when publishing".
Expected Behavior
I expected this notation to not be marked as an error, as the documentation clearly documents this as a valid option.
Steps To Reproduce
$ npm init
"bin": "path/to/file.js"
$ npm publish
Environment
The text was updated successfully, but these errors were encountered: