Repository navigation
Document how to specificy non-production files in package.json. #209
Description
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.
Activity
mhdawson commentedon May 13, 2019
From minutes:
files are needed for production (possibly through globs)
that support the ability for consumers to choose how much to install
jchip commentedon May 27, 2019
Given that npm already has
.npmignoreandfilesto filter what to publish, I think we just need a way to specify what files are needed for production. Like a newprodFilesin package.json. The tool would remove all files not included in that.@ljharb What are your thoughts?
ljharb commentedon May 27, 2019
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 commentedon May 31, 2019
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
prodfileskey, 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 commentedon May 31, 2019
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 commentedon May 31, 2019
The CITGM folks probably also have thoughts about this?
dominykas commentedon Jun 1, 2019
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 commentedon Jun 1, 2019
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.
jonchurch commentedon Jul 29, 2021
This isn't listed on the 2021 Projects. I don't know if any thinking has changed on this topic, or if it's still a priority of the group.
Marking as
stale?to bring attention to it.