Conform to Babel plugin naming scheme

[jamiebuilds]

Hiya, since this is just a Babel Plugin it should be following the babel plugin naming scheme.

babel-plugin-descriptive-name-of-what-it-does

I'm sure you spent a lot of time thinking of kneden, and it's nice but it'd be better to respect community standards.

[ljharb]

[marten-de-vries]

This project didn't start out as a Babel plug-in, it originally used straight up acorn/estraverse. I then chose the package name, and published to it. I saw no reason to change it after the conversion to Babel. (This was all pre-1.0.0, and Babel seems to support both "babel-plugin-name" & "name" just fine in .babelrc. I saw the babel-plugin- convention at that point, but didn't know about the descriptive name convention until you mentioned it.)

I certainly don't want to play down play Babel's role in this project, but I don't think I do so either: it's clearly mentioned in the README, the Github description, on npm and in the Hacker News post I used to introduce the project.

I could register, say, babel-plugin-async-to-promise-chain, but the project's name has spread now so that will cause at least some confusion. Is it really worth it do so, now?

[jamiebuilds]

Part of the reason, or at least one of the big benefits, for the descriptive naming is to make .babelrc's easier to follow from newcomers:

plugins: [
  "transform-remove-debugger",
  "transform-simplify-comparison-operators",
  "transform-strict-mode",
  "transform-react-display-name",
  ...
]

Having kneden dumped in the middle just means that you now have to google to figure out what it does.

[marten-de-vries]

@thejameskyle Thanks for the quick response.

At this point I'm against breaking the npm package & the name recognizability, but it would be possible to fix the particular problem you name by publishing a small wrapper package babel-plugin-transform-async-to-promise-chain that depends on the kneden package, and making it the default entrypoint in the documentation. Both names could be mentioned in the README.md file in text (e.g. title) to make search engine users happy.

Would that work, or are there any other reasons to take into account?

[marten-de-vries]

As a side node, your last comment would in my opinion be a nice addition to your plugin handbook. If I had read it while converting to Babel, and I did read the complete handbook then, I probably would've switched then, avoiding the issue. :)

[AprilArcus]

If it's up for a vote I'm in favor of a prosaic name like babel-plugin-async-to-promises with an eye toward eventual inclusion in the Babel multi-repo over babel-plugin-async-to-generator. There's no reason this shouldn't be the default after all the bugs are worked out; it has a significant performance advantage and would be of broad general benefit to the JS community.

I retract bikeshedding.

[jamiebuilds]

There's only a handful of users of kneden today. In my experience, changing the name early on is better than later.

If you just rename this package and publish it under the new name, you can npm deprecate this package and leave a deprecation warning pointing people where to go.

[marten-de-vries]

I just switched the npm package name to babel-plugin-async-to-promises. The 'kneden' package is replaced by a dummy package which points to the current version of the former. I plan to keep that up to at least the next major release.

In the long term, I might fully phase out the name Kneden, but for now I'm happy with the current approach: using a descriptive npm package name & naming both in the README. Thanks for the input everyone!