Disallow plugin/preset shorthand names from babel@7 onwards

Feature Request

Currently you can drop the babel-preset and babel-plugin prefixes. https://babeljs.io/docs/plugins/#pluginpreset-shorthand

"presets": ["@org/babel-preset-name"]

shorthand

"presets": ["@org/name"]

I propose for babel@7 we prevent this and only allow full names to be used.

Why?

• It makes it more difficult when refactoring because you have to search for two names instead of one.

  • This makes removing all instances of a plugin in a monorepo harder than it should be.

  • There is the potential for clashes such as @babel/foo and @babel/babel-preset-foo.

  • Say you develop your own plugin, and want to rename it, and its used in every package in a monorepo. This because very difficult when you cannot rely on every usage being named the same.

• It adds complexity to parsing babel plugin/preset names. Other tooling has to parse these names such as ava, and they need to implement this complicated logic.

• The way it works with package @scopes makes it awkward, because its no longer dropping a prefix, its dropping from the middle.

Teachability, Documentation, Adoption, Migration Strategy

babel@7 would be a great time to do this because everyone is already renaming everything to be @babel prefixed anyway.

[loganfsmyth]

Say I have a tool to check if a package specified in my package.json is used in my codebase. Babel will always be a special case, and makes a simple checker quite complicated.

I think no matter what that will require linting guidelines. If we changed to requiring the prefix, users could just as easily turn around and do

presets: [
  'env',
  'react',
  'flow'
].map(n => `@babel/preset-${n}`)

and you’d have the same issue, and it’s now more painful for users.

Ignoring that usecase and the edge cases though, I do understand where you’re coming from. I just think you’ll encounter this issue with any package that implements a plugin system. ESLint for example also does not reference the prefix in their config.

[hzoo]

seeing as the usage is already very widespread and people are starting to adopt babel@7 already in a big way.

Yeah I think we don’t get much but we can definetely try to lint either in a tool like https://github.com/sonarwhal/sonarwhal or if we introduce our own type of thing