Only include "index.js" in published NPM modules

[tobiasbueschel]

Hi @kesne,

Thanks for your work with this library 🙏

I noticed that the test folder, .npmignore and .travis.yml are published to NPM:

In the spirit of keeping the distributed module size small, this PR whitelists index.js :)

Cheers

[Raynos]

:-1:

Publishing the entire source code is good. I want to see the tests and other code in my node_modules when i install dependencies.

[Matt-Esch]

@Raynos published builds are considered ready for production, correct? This is why npm doesn't install dev dependencies. So why would you want to include test files in your production builds? It makes no sense to me. Test files should be purged from production where possible and we publish production ready modules to npm.

[ljharb]

@Matt-Esch npm install foo && npm explore foo && npm install-test is an important workflow to preserve.

[Raynos]

published builds are considered ready for production, correct? This is why npm doesn't install dev dependencies. So why would you want to include test files in your production builds?

When you install a dependency you want to see the source code of that library. Every dependency you install is one you effectively maintain.

It's frustrating to maintain a dependency if you cannot go into that module and see it's documentation and tests to see what the hell it's doing.

If you want a smaller production build you can explicitely trim node_modules by identifying what your binary requires and deleting all other files.

You need this anyway for tree shaking when you import a large library and there is unused code.

This is why npm doesn't install dev dependencies.

The reason you do not want to see dev dependencies in your production build is because you don't want to maintain all your dev dependencies and all your production dependencies.

I like having eslint I don't want to maintain or rewrite it if it breaks, I want it to just work and maybe hack around it if it's frustrating. Other production dependencies I have to maintain or rewrite if they break because they effect the production artifact and the end user experience, eslint does not.

[Matt-Esch]

When you install a dependency you want to see the source code of that library. Every dependency you install is one you effectively maintain.

I want to see the source code that executes in production, because that's what I effectively maintain.

It's frustrating to maintain a dependency if you cannot go into that module and see it's documentation and tests to see what the hell it's doing.

There are multiple levels of "go into" here. I "go into" modules by using the debugger. I also "go into" modules by cloning the associated repositories. I can't maintain code without a repository to contribute to so if I'm having trouble with a module I will always go the npm page and the github repository. I make changes and test them in my code with npm link.

If you want a smaller production build you can explicitly trim node_modules by identifying what your binary requires and deleting all other files.

It's near impossible to define a tree shaking operation that magically knows how to trim all the fat out of node_modules. Require isn't the only way to depend on resources. The best way to know what to trim is if we define what is production and what isn't. Tree shaking also has no improvement on install times, which only removing from the published modules will.

I think this is just a mismatch of values. I care most about the production artifact. The best production artifact is one that is properly trimmed and has a reduced surface area. It's one that takes a short time to build. I care less about the developer experience when it comes to debugging nested modules as I don't find the alternatives too cumbersome. I'm not convinced the cost of this is worth the value it provides. My opinion probably isn't in the majority within this community.

[Raynos]

The best production artifact is one that is properly trimmed and has a reduced surface area. It's one that takes a short time to build.

This is a build time problem. You can trim the module. Just ask node what was required when doing node server.js and delete unneeded files.

If you want fast build times build a cache based on package-lock.json

If you want fast incremental cache then use git log package-lock.json to install the old snapshot and patch in just the tarballs that changed

If you want fast installations with no cache, on a brand new machine then that’s a seperate problem. I doubt tarballs size is the biggest problem, like a 4kb and 8kb tarball will download just as fast. Do you think the number of files in the tarballs impacts the total installation time significantly or is untar around blazing fast ?