Naming standard for new binding projects?

I’m about to publish some bindings for fast-check, which I wrote long enough ago that they are named bs-fast-check, but it occurs to me that this question was never answered:

Should I use res-fast-check? or maybe rs-fast-check? I’m not sure :thinking:

2 Likes

i have no official answer to that question, but i always felt that rescript-my-binding was always better than any version with an acronym like re-, res- or bs-.

Some bindings even put that extra info in the module name (like the legacy ReasonReact), which imo is super redundant.

1 Like

I’m using "namespace": true, so that would mean my module entry point is RescriptFastCheck instead of ResFastCheck or similar.

However after re-reading the documentation I realised setting namespace to a string is actually a supported and welcomed config now. I thought it wasn’t, my knowledge is a bit out of date :sweat_smile:

1 Like

Yeah in that case, just FastCheck would definitely be better than ResFastCheck or RescriptFastCheck, no matter what the npm package is being called.

bs-platform will be soon published as rescript on npm, and some core packages will most likely be published under the @rescript npm organization, so it would make a lot of sense to have complementary community bindings like rescript-fast-check, rescript-webapi,… to match the theme?

Naming things is really the hardest problem, especially on npm.

2 Likes

Ok yes I’m going with rescript-fast-check. I suspect part of the reason the bs- prefix became popular - aside from the obvious shorthand for “BuckleScript” - is that it matched well with bs-platform. If the core package is changing, it makes sense to follow.

2 Likes