Giters

alexreardon / tiny-invariant

A tiny invariant function

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

More meaningful name for `invariant` function

cjoecker opened this issue · comments

commented

I would like to have a more meaningful name for the function than invariant. Something like throwOnFalsy 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 the invariant 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.

commented

I'm not sure the name is totally confusing but perhaps something like isNullish?

commented

I agree entirely that invariant is not a great name. Personally, I think assert would be a way clearer name than invariant. However, leaning on invariant means that tooling that automatically allows invariant messages to be stripped (eg https://www.npmjs.com/package/babel-plugin-dev-expression) just works™️

Personally, I would like to see us move away from invariant towards assert. I am exploring making a new (ESM only) assert package: https://github.com/alexreardon/tiny-assert

commented

@alexreardon I like the assert!
I’m just wondering if it makes sense to make a new library for that.

tiny-invariant is already known in the community. Maybe it would b le better to leave the name for recognition purposes and just add a new function. Many brands preserve historical names just to allow the people to find them back.

commented

@cjoecker Would it help your issue if you did import assert from 'tiny-invariant';?

commented

@sandinmyjoints yeah! That would be more intuitive and the name of the library remains the same 💯

commented

I guess this package tiny-invariant could just re-export the default function as a named export assert.
So that people could do:

import { assert } from 'tiny-invariant';

Autosuggestion and autoimport of IDEs (e.g. VS Code) would probably benefit from that.

commented

My only concern is that adding some name exports makes this "tiny" package a bit larger than it needs to be 🤔

commented

@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?

commented

I made the code changes to export invariant as assert too here: master...pkerschbaum:tiny-invariant:feat/export-as-assert.
To determine the increase in size, I created the .tgz files which would get published to the npm registry (by running yarn pack). Both of the current master and of the feature branch.

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 :)

commented

I made the code changes to export invariant as assert too here: master...pkerschbaum:tiny-invariant:feat/export-as-assert. To determine the increase in size, I created the .tgz files which would get published to the npm registry (by running yarn pack). Both of the current master and of the feature branch.

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!

commented

I agree entirely that invariant is not a great name. Personally, I think assert would be a way clearer name than invariant. However, leaning on invariant means that tooling that automatically allows invariant messages to be stripped (eg https://www.npmjs.com/package/babel-plugin-dev-expression) just works™️

Personally, I would like to see us move away from invariant towards assert. I am exploring making a new (ESM only) assert package: https://github.com/alexreardon/tiny-assert

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).

commented

Opposite opinion: I love invariant, over any others words. This makes me think of the DDD invariant (strong business rule that must be enforced). It make the intent very expressive