Ensure no extraneous files get published

[jfmengels]

I think it will be nice if, before publishing, np checked whether the package has either:

• set a files field in package.json
• a .npmignore file

This would help publishers make cleaner packages and reduce the bandwidth used when installing the resulting package.

I would actually advocate towards making sure there is a files field, as it's better IMO than using .npmignore, but that's just my opinion. A well designed .npmignore has the same result.

---

IssueHunt Summary

bunysae has been rewarded.

Backers (Total: $60.00)

• issuehunt ($60.00)

Submitted pull Requests

• #456 Show files added since the last release and not part of the package

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[sindresorhus]

👍 👍 I can't believe I didn't think of that. I'm like the biggest proponent of the files property.

How about failing if there's neither and warn about recommending files if there's a .npmignore?

[jfmengels]

I had the same thought :D

I'd be fine with that. I think you should you be able to force through the error with an option though.

[sindresorhus]

I think you should you be able to force through the error with an option though.

Why? There's absolutely no reason to not use either files or .npmignore.

[SamVerschueren]

I agree with Sindre. It gives me the creeps to see test files being part of a shipped dependency...

[jfmengels]

I'm thinking of the case when you started a new repo and want/need to publish it quickly for some reason and you don't want to mess up the package by quickly adding a files property without checking it's right. Maybe you don't have the time to check it because it's very urgent and you'd need to make a PR to add the files field and get it approved by your team, etc...

Ok, maybe it's a bit farfetched, I agree. But other than this case, I don't see a good reason no.

I thought about letting this pass when the package is so simple that it would not publish anything extra anyway, but I'm not sure it's worth going through the trouble of implementing it for what seems like a very edgy case.

you want to publish your repo for the

[SamVerschueren]

I would suggest adding this functionality without an option. If someone comes up with a valid use case, we can always reconsider.

[jfmengels]

Yeah, let's do that. Anyway, if this case comes up, they could still use the original npm publish

[voxpelli]

The only thing that makes me a bit anxious is that of the two solutions, files and npmignore, both require that all team members remember to either add new files that should be ignored to npmignore (failure could in worst case result in uploaded secrets) or to add new files to files (failure to do so could in worst case result in broken code).

Currently I have opted to push for np internally at work as it's the most fool proof way of publishing new versions of npm packages – with the running of tests and everything.

Will be hard though to test whether files includes everything it should or whether npmignore ignores everything that it should. Enforcing that ones always use one or another in a team that isn't used to working with them sounds like a recipe for broken packages.

I'm 👍 on adding a warning though, especially as a first step, to nudge people in this direction. If one could then somehow add a safety net to catch missing additions to either files or npmignore then I would have no problem with enforcing it either, but unfortunately I don't think such a safety net can't be constructed.

[sindresorhus]

either add new files that should be ignored to npmignore (failure could in worst case result in uploaded secrets)

How is this worse than not using .npmignore though?

Will be hard though to test whether files includes everything it should

See: #82

[voxpelli]

@sindresorhus It's worse as .npmignore overrides .gitignore, which hopefully everyone knows how to use, so anyone who expects a file ignored in .gitignore to be excluded from publishing (as is the default of npm) will accidentally be publishing files it shouldn't

[fregante]

Related: perhaps there can be a size check too/instead. Shipping a hundred 1KB files (like tests, usually) is not as bad as a 5MB package. To put things into perspective, all babel's tests take 750KB of disk space (although they are 4000 files)

[fregante]

@voxpelli gitignore might be ignored at some point:

Stop using .gitignore as a fallback for .npmignore npm/npm#12331

[voxpelli]

@bfred-it Totally and that would solve my anxiety here that enforcing a mechanism like this on people not expecting a mechanism like this will result in them doing things that goes against their intentions.

But we're not there now so until we are I will be restrictive in adding either files or .npmignore to projects as the risk of someone forgetting to update them is too large and I would like it if np allowed me to keep it that way as all of the rest of np:s features helps people in delivering on their intentions rather than enforces things that might have them do the opposite.

So I'm 👍 on any nudging to raise awareness about this issue in the meanwhile though, but 👎 on any enforcing until a change like the one you mention has been implemented.