Closed dmattia closed 4 years ago
Hmm tough call, these files aren't required at runtime are they? Just compile-time? My original plan was just to remove all stuff that is non-essential for deployments
Correct, they are just for compile time, so that makes sense!
What if I had the default list of ExceptionGlobs as empty, but let it be overwritten by a flag? So typescript folks could optionally do:
node-prune --exception-globs "*.d.ts,tsconfig.json" ./node_modules
Would that be preferrable?
Yeah --include, --exclude
flags might be nice, sounds fine to me!
@tj any way this getting released soon? We're having problems with the .d.ts right now :)
@tj Updated to add --include
and --exclude
flag options, both accepting regex strings, both defaulting to empty
^ some examples of usage
awesome thanks!
This seems to be released, but when fetching the newest version there is no --exclude
flag?
looks ok to me!
λ curl -sf https://gobinaries.com/tj/node-prune | sh
==> Downloading github.com/tj/node-prune@master
==> Resolved version master to v1.2.0
==> Downloading binary for darwin amd64
==> Installing node-prune to /usr/local/bin
==> Installation complete
λ node-prune -h
Usage of node-prune:
-exclude value
Glob of files that should not be pruned. Can be specified multiple times.
-include value
Globs of files that should always be pruned in addition to the defaults. Can be specified multiple times.
-verbose
Verbose log output.
Maybe you have another version installed elsewhere? (`which node-prune)
Thanks a lot @tj I still had an old curl, which fetched the old version.
For anyone looking for a quick copy and paste:
node-prune --exclude "*.d.ts" -- exclude "tsconfig.json" ./node_modules
(Multiple --exclude
flags are the key here).
Fixes https://github.com/tj/node-prune/issues/65
Files matching the regex "*.d.ts" will not be removed from
node_modules
.Up until now, this library hasn't done two things: used regex anywhere or had exceptions to the default rules. This largely makes sense, as the current whitelisted dirs/files/extensions can be put into maps with O(1) lookup times.
This PR adds regex based exceptions, which cannot be put into a map, so the time complexity will be O(nm) where n is the number of regexes we whitelist as exceptions, and m is the time complexity to compute the regex.
I am going to argue that as long as the regex list is kept small (which I put in a comment in the code) that the practical time difference will be minimal.
Here is me running my forked tool over a 1.4GB monorepo:
And here is a run over the same 1.4GB node_modules using the tool at HEAD:
On repeated runs, they seem to execute in roughly the same time frame, so the performance impact of this PR seems negligible.