-
Notifications
You must be signed in to change notification settings - Fork 130
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
Do not prune *.d.ts files #66
Conversation
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 |
@tj any way this getting released soon? We're having problems with the .d.ts right now :) |
@tj Updated to add |
awesome thanks! |
This seems to be released, but when fetching the newest version there is no |
looks ok to me!
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: (Multiple |
Fixes #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.