Open Glinkis opened 5 years ago
A better solution is to only include the relevant files
Can you elaborate as to why this would be better?
The node_modules
-folder of the average project is becoming really large, so we should do everything we can to keep published projects small.
And why would I, as a consumer of your library, be interested in any other files than the ones I consume?
You don't ship your tests to your clients, do you?
The node_modules-folder of the average project is becoming really large, so we should do everything we can to keep published projects small.
The size I care about is the change in the runtime assets of the consuming project that a library contributes to (~172 bytes in this case). I don't see lots of tiny files/folders in node_modules
as an intrinsic problem.
And why would I, as a consumer of your library, be interested in any other files than the ones I consume?
You may be interested in looking at tests, as it's one of the most accurate sources of information for learning about what a piece of code is designed to do
You may be interested in the original source code, so you can make changes to the original .ts
file, and generate a new .d.ts
to see the ramifications of your changes.
You may even be interested a library's yarn.lock
, if while troubleshooting, you have a need to know whether the specific tarball you have was tested against a particular version of something.
So there are very tangible benefits to including these -- I've saved my consumers the trouble of finding the source code, going to a particular version, making sure that it aligns with what was actually published to NPM, etc...
When this package is published to npm, it currently includes the whole project.
A better solution is to only include the relevant files, which in this case should only be
index.ts
.This can be achieved by setting the
files
property inpackage.json