Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only publish relevant files to npm #79

Open
Glinkis opened this issue May 8, 2019 · 3 comments
Open

Only publish relevant files to npm #79

Glinkis opened this issue May 8, 2019 · 3 comments

Comments

@Glinkis
Copy link

Glinkis commented May 8, 2019

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 in package.json

@mike-north
Copy link
Owner

mike-north commented May 8, 2019

A better solution is to only include the relevant files

Can you elaborate as to why this would be better?

@Glinkis
Copy link
Author

Glinkis commented May 9, 2019

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?

@mike-north
Copy link
Owner

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants