Skip to content

whitelist index.js when publishing NPM module #7

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

Open
tobiasbueschel wants to merge 1 commit into
base: master
Choose a base branch
from
Open

whitelist index.js when publishing NPM module #7

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
3 changes: 3 additions & 0 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,9 @@
},
"homepage": "https://github.com/juliangruber/array-filter",
"main": "index.js",
"files": [
"index.js"

@ljharb ljharb May 25, 2019

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

The “files” field is dangerous - the only way published files should ever be restricted is by npmignore.

@customcommander customcommander Apr 18, 2021

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I neither agree nor disagree with this statement but is there a particular issue you are thinking of with this project? From what I can see the tests do not test a specific module but the package as a whole (i.e. require('..') vs require('../index.js')) which I think is a really good practice as it will also highlight (although indirectly) any packaging issues.

I suppose files is more of a "publish nothing by default" policy and .npmignore is more of a "publish everything by default" policy. I tend to favour the files option as it somehow mitigate the risk of publishing "secrets" by accident.

@ljharb ljharb Apr 18, 2021

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

That’s an accurate analysis - there shouldn’t be any secrets in the repo in the first place tho, and rotating secrets is far easier than un breaking millions of downstream builds, which is the (much more problematic) risk of the files option.

these days both GitHub and npm auto-detect many published secrets, and disable the ones they know about. It’s just not a real problem.

],
"scripts": {
"test": "tape test/*.js"
},
Expand Down