Rename .gitignore to .npmignore in package if no .npmignore found
isaacs opened this issue Β· 16 comments
When packaging up a folder, if there's a gitignore file and no .npmignore file, add it to the tarball as .npmignore.
Always exclude .gitignore files from packages.
This is to better support the "check node_modules into git" approach.
+100 on this.
I've lost count of the number of times I've managed to check in a dependency without realising that its dependencies are missing!
This "feature" threw me off for a long time when trying to package my first node library.
I am generating the code from coffeescript, so while my package.json
contains this:
"directories": {
"lib": "./lib/coffee-scope"
}
my .gitignore
has a /lib/
entry (because I don't want the generated code checked in). The result is that the packaged library is missing /lib/
and is therefore completely broken.
Regardless of whether my approach is ideal, the behavior is very confusing. I wouldn't expect that my .gitignore
would have an effect on how npm behaves.
I would suggest one or more of the following changes:
- Don't automatically rename
.gitignore
to.npmignore
. - If you do rename
.gitignore
to.npmignore
, remove entries which would exclude files and directories specifically required inpackage.json
. - Document this feature in
npm help json
. I read that help file thoroughly and explicitly chose not to include a.npmignore
file for my project, and only realized that this.gitignore
magic was happening after I found this github ticket.
The directories.lib
field is completely for human consumption. npm does not do anything interesting with it.
.gitignore files are only renamed to .npmignore when they're treated as such. If a .npmignore file is already present, then .gitignore files are excluded. This is to make it easier to check node_modules folders into source control for deployed apps.
Doc patches are always welcome, but the behavior is not going to change.
Thanks for clarifying, @isaacs.
I made a pull request for a tweak to the docs that would have helped me out, at least.
I can see why removing .gitignore
might be desirable, assuming you want to encourage people to check in their node_modules
folder, but this
.gitignore files are only renamed to .npmignore when they're treated as such.
doesn't really make sense to me. How can you assume that the files that people want git to ignore are the same that they don't want included in their package?
Given the number of complaints I'd received from people who accidentally published stuff that's .gitignore'd, vs the number of complaints from people who accidentally didn't publish stuff that's .gitignore'd once the change was made, yes, the data is overwhelmingly not in your favor here. There's no way to not confuse anyone. Even that sentence is sort of confusing.
This design really becomes a bit draconian when creating yo modules to setup new projects - particularly where you want to include a .gitignore file - this hidden 'feature' breaks my yo generator that has a .gitignore (by renaming it to .npmignore).
Besides, I don't want node_modules checked in - I want to force developers to define explicit versions in their package.json and require an 'npm install' upon code checkout to assure packages are explicitly listed or the build fails (particularly on the build server). We have a private repo and caching proxy to assure these dependencies aren't lost and our more frequent installs don't impact the public npm repo.
This is breaking my yeoman generator, as well: Lostmyname/generator-component#1
Is there any reason to completely remove the .gitignore? It only saves a few bytes, but it messes up Yeoman and ember generators (see some of the issues above).
Yepp also breaking my generator. I have a templates/.gitignore file, which in fact is just a template file. I guess I should just rename it to gitignore in it's template form. Either way, a bit annoying to have third party code screw with your files.
@JaysonRaymond @callumacrae @kosz Can we center the generators discussion at #7252? It would be nice if we could come up with a solution that solves both use cases.
Thanks!
Is this supposed to rename all .gitignore
files to .npmignore
if it doesn't find it, or just the .gitignore
on root?
I have a template .gitignore
file in a templates
directory that is getting renamed along with the root .gitignore
as well.
I have a blank .npmignore
file in my project root, yet when I publish templates/.gitignore
is renamed to templates/.npmignore
.
Am I doing something wrong?
Both .gitignore
AND .npmignore
are processed at every level of the directory tree by both git
and npm
respectively, which is why the rename feature occurs at every level as well.
I mentioned this over on twitter, but since I can be more verbose hereβ¦
You might find something like tacks helpful in turning your templates
folder into js that you can call to recreate that folder later. I originally wrote it to make creating test fixtures easier, but it's well suited to generators as well.
Using it would look something like this:
From your commandline:
$ tacks templates/ > templates.js
And then from your generator:
var templates = require('./templates.js')
templates.create('/path/to/generated/folder')
Since it's distributed as a plain JS file, it won't get stepped on during publish.
@iarna Thanks for the suggestion (and your time on twitter/here). I don't think it's the right fit for our project, as (I think) it would require pre-compilation by generator authors before publishing to npm, which would be an awkward fit with our streamlined generator workflow.
For us, I think a better solution is going to be clear documentation that if authors wish to use .gitignore
in their generators, they will need to name their files .##gitignore##
, which will be a value gitignore
set to the same string gitignore
.
In this way, the file that gets published as a template file to npm is called .##gitignore##
and won't get caught by npm, but then later it gets replaced with the string to be .gitignore
.
Is there a page of documentation for npm that explains all possible file alterations upon publishing? Specifically, I'm wondering if package.json templates will also be changed.
not yet, @dcrockwell, but there can be. (i write docs at npm)
@ashleygwilliams Excellent. I think that would help out a lot for folks building systems on top of npm.
I appreciate both @iarna and your (@ashleygwilliams) time in looking at this somewhat older issue. I recognize that our project's use case is fringe as compared to those that were burned by the .gitignore issue that this solves.