Document how to specificy non-production files in package.json.

[mhdawson]

Explore tools to remove non-production files
Explore tools to help maintainer generate package.json sections
(later) talk to npm about integrating support for the new package.json section.

[mhdawson]

From minutes:

• Document the “paved paths”
• Propose a process for packages maintainers to indicate explicitly which
  files are needed for production (possibly through globs)
• Make a tool for maintainers to get feedback and suggestions to drive dev decisions
  that support the ability for consumers to choose how much to install

[jchip]

Given that npm already has .npmignore and files to filter what to publish, I think we just need a way to specify what files are needed for production. Like a new prodFiles in package.json. The tool would remove all files not included in that.

@ljharb What are your thoughts?

[ljharb]

I think the combo of “publish all files”, a “prod files” package.json spec and a tool to validate it, and a tool that can prune all non-prod files from node_modules recursively, would be super useful.

Especially given tink’s direction, this seems like a good approach.

[wesleytodd]

I have been absent, so sorry if this question has already been answered. What happens when an app "worked in staging" because of using this? Unless we also somehow recommend that app developers use this tooling in their test environments, it seems like this will be a common occurrence. And even then it will just be, "worked on my machine".

In my experience, having used browserify to achieve something similar, module authors do all sorts of weird things, and if some transitive dependency starts publishing a prodfiles key, and my production build was for some reason requiring one of those files, it might be pretty hard to debug.

When we did this with browserify we had to manually include some files because browserify was unable to infer it. I assume our tooling would need to something similar to verify that all required files were also included in the prodfiles, so how will we solve this differently than browserify does to avoid that problem?

[ljharb]

That’s a really good point - nobody who’s using files or npmignore is likely running CI against an npm pack version of their package, which would be the same effective step required to test “prodfiles”.

Maybe we should put this a bit on hold, pending an effort to develop and recommend an easy way to run tests (both locally and in CI) against the package files that will actually be published? (since many folks using transpilers test the raw source and not the build output, this might be a very difficult problem to solve)

[vweevers]

to run tests (both locally and in CI) against the package files that will actually be published

The CITGM folks probably also have thoughts about this?

[dominykas]

Maybe we should put this a bit on hold, pending an effort to develop and recommend an easy way to run tests (both locally and in CI) against the package files that will actually be published

Not sure why would this need to be on hold? Files/npmignore is already in the wild, prodfiles (and prodignore?) Is just an extension of that? And whether the tests get built first or the spec is a bit of a chicken/egg? But also not entirely necessary, given the existing patterns of files/npmignore (include lib/src, exclude tests - the obvious stuff applies to majority of the cases).

[ljharb]

I’m talking about prodfiles itself - pushing a new package.json field to the community is a big deal and shouldn’t be done lightly.

I agree that files/npmignore is already in the wild, but so too is “not actually testing the real list of published files”, and recommending another mechanism of restricting published files seems dangerous without that testing.