sam-github
commented
9 years ago Its an interesting tweak. You'd have to re-write this single line, https://github.com/strongloop/strong-build/blob/master/lib/git.js#L134, into a fairly complex beast that recurses from ., checking all files against the .npmignore, and adding them one-by-one to the cache. Or maybe you could find a way to make git ignore the .gitignore, and use the .npmignore in its place, so git would do the work for you?
As you say, unless your test folder is unreasonably large, stripping bits of your repo out of the deploy branch doesn't seem critical.
I think you could do this with a build script, too. If you add a script with name "build" into your package.json, it will be run before the git add. If you had a script that did something like for $L in $(cat .npmignore); do rm -rf "$L"; done that would remove everything you didn't want before git add added it. Generally the build script is used to create new files (runs bower, or whatever), but I think it could be used to remove files, too, though I've never tested that.
It seems that the .npmignore file is only observed by the --pack option, not the --commit option. I woud prefer to use git as the mechanism to store our versioned builds, but obviously the git repository for my project contains a test folder for my tests. If I add 'test' to .npmignore and pack a build into tgz then the test folder (and anything else in .npmignore) is not included... alas if I commit a build to a deployment branch and then git clone/pull from this branch on the production machine, the test folder comes along for the ride.
I suppose there is perhaps no harm in these things hanging around on the production machine, but I'd prefer that they weren't there. (This also goes for things like IDE project files which are committed to git, but I would also add to a .npmignore file to have them excluded from the package or deploy branch commit).