-
Notifications
You must be signed in to change notification settings - Fork 48
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
More meaningful name for invariant
function
#153
Comments
invariant
function
I'm not sure the name is totally confusing but perhaps something like |
I agree entirely that Personally, I would like to see us move away from |
@alexreardon I like the
|
@cjoecker Would it help your issue if you did |
@sandinmyjoints yeah! That would be more intuitive and the name of the library remains the same 💯 |
I guess this package import { assert } from 'tiny-invariant'; Autosuggestion and autoimport of IDEs (e.g. VS Code) would probably benefit from that. |
My only concern is that adding some name exports makes this "tiny" package a bit larger than it needs to be 🤔 |
@alexreardon that’s an interesting point. Two questions comes to my min: how big is the impact of that extra export? How relevant is that increase in size having into account that npm does tree shake and only compiles the code that is really being used? |
I made the code changes to export invariant as The size of the master .tgz package is 4668 bytes, that of the feature branch is 4720 bytes. Thus the size of the NPM package would increase only by 52 bytes. I think this represents the "upper bound" of size increase consumers of the package would have - with tree-shaking and stuff like that it would probably be even less. I would say the increase of the size is no problem :) |
Looks nice! Thanks for the PR! |
I think if terser/terser#1080 were fixed, then the name could be anything and messages would still be stripped (at least when using Terser). |
Opposite opinion: I love |
I would like to have a more meaningful name for the function than
invariant
. Something likethrowOnFalsy
is for me easier to understand.While working with developers that don’t know what
tiny-invariant
is, I realized that is not easy understand at first sight what theinvariant
function does. To improve this, it would be nice to rename the function with something more descriptive. I would still keep the original function to avoid breaking changes but also allow to import the new function with the descriptive name.What do you think? Is
throwOnFalsy
good for you or maybe you have a better name?If you think it is a good idea, I would submit a PR for that.
The text was updated successfully, but these errors were encountered: