Suggest using pkg.files

[bluwy]

In many cases where pkg.files is not used, and superfluous files/directories, such as tests, __tests__, .prettierrc, .eslintrc, etc are published, it would be good to suggest adding a pkg.files field to prevent publishing them.

[ericcornelissen]

First off: I really like the idea of this rule 😃

However, I think the current implementation is not ideal. I think there's two problems with the current approach:

First and foremost is that the use of an .npmignore file by a package is currently not taken into account, I think this should also be used as a signal that internal files/folders are being ignored¹. This is currently causing false reports on all my npm packages.

A second issue is that even if "files" (or .npmignore for that matter) exist, the listed files/folders may still be published - the current implementation does not take this into account. I don't know the feasibility of this suggestion, but I think looking for "internal tests or config files" inside the packaged tarball instead would be a less error prone way to determine if there are files/folders that shouldn't be published.

I also think the current messaging is potentially confusing. It states that "[t]he package publishes internal tests or config files." Signalling certainty, even though the rule is very much an approximation. So I think wording like The package may be publishing internal tests or config files may be more appropriate.

Footnotes

1. I know there's debate about using .npmignore or the files array. Ultimately, as long as npm supports .npmignore I think it would make sense for this tool to support it. ↩

[bluwy]

First and foremost is that the use of an .npmignore file by a package is currently not taken into account

Thanks for catching that. I released v0.2.4 to fix it. I wasn't matching against the packed files (from npm-packlist) when checking for those.

A second issue is that even if "files" (or .npmignore for that matter) exist, the listed files/folders may still be published - the current implementation does not take this into account.

This was an intentional decision here. "files" uses an opt-in style, while .npmignore uses an opt-out style for declaring files to publish. The goal is that if you're using "files" to even include test or config files, it will think that it's intended. There could be packages out there wanting to publish these (for whatever reason) and I don't want to prevent that.

However, I didn't do the same for .npmignore due to its opt-out nature. It's common that you're creating new tests for your existing project and you forget to list it in .npmignore, so that's usually not intentional and publint will do a more thorough check.

I also think the current messaging is potentially confusing. It states that "[t]he package publishes internal tests or config files." Signalling certainty, even though the rule is very much an approximation.

It is true for many cases though. If there's a very high chance that it's correct, I think it's good to signal that certainty so people are willing to double check their published files. In this case, it's my bad that I introduced a bug that made this untrue for a good portion of cases, but now it should be more solid.