Use .npmignore about mercury HOT 11 CLOSED

disk space is cheap.

Having a local copy of examples, docs & test is invaluable.

Why bother keeping package size down ?

from mercury.

Hey. Local copies of those things seems to be very rarely used both in my experience and in how others describe their experiences. Cloning the repo is cheap if you need to reference all that stuff locally rather than online. What is a common situation though is checking in node_modules; leaving all this cruft in the repo is a hassle for developers. npm-shrinkwrap is not a solution to avoid checking-in code that will be part of production, because it doesn't make any promises about the byte-level integrity of a package.

from mercury.

For those who check node_modules in they should just ignore non javascript files inside node_modules.

If your going to check node_modules in you need a solution to deal with git weight / size / history problems.

There are multiple userland implementations of something like npm-shrinkwrap that have byte level integrity, i.e. implementations of checksums in userland.

I personally find local copies in node_modules really helpful for reading documentation offline, git cloning every module I use is not needed.

from mercury.

yeah, i'm torn, because on the one hand it makes sense to keep the package size down for 99% of cases where you don't need the docs and tests, but on the other hand i've had experiences with no internet access where having the docs and tests already available was awesome.

from mercury.

Packages are necessarily consumed for production but not necessarily consumed for development. For that reason, I don't packages should exclude development artifacts such as testing. Documentation is arguable, but I would lean against including that as well.

from mercury.

npm packages are not for production.

You want to build a production tarball, build one and strip it down however you want. You cannot fix npm to be how you want it to be, you will always need to do your own production tarballing.

Npm is an amazing tool because it optimizes for development workflows, good testing, good publishing, good authoring

from mercury.

we clearly have different perspectives on this.

your package is distributing a lot of JS files that aren't part of the functional module. rather than asking people to try to deal with excluding the idiosyncratic internals of individual packages, you could help to make sure that what ends up on npm is largely code required for this module to function. then you cater for the 99% case that most other people are catering for. there's a difference between building production assets and what is on the file system. git-clone is the better way to get the complete package code.

from mercury.

not going to push you on this. i respect what you want to do with your own project :). thanks for hearing me out and for working on this stuff!

from mercury.

@necolas would adding checksum support to ( https://github.com/uber/npm-shrinkwrap ) help with this problem ?

from mercury.

probably not for us, because we can't depend on npm being up to deploy (but we have a place to store copies of approved modules). but that package looks useful anyway because the from noise in the npm-shrinkwrap.json commits is pretty ridiculous.

from mercury.

We use npm-shrinkwrap in combination with a npm mirror we maintain.

npm-shrinkwrap just solves the determinism problem whilst only checking the minimal information into git.

We have a npm mirror to solve the "cant rely on npm" problem and we have a build artifact server to solve the "dont build the same git sha into a binary twice" problem.

from mercury.