Vue-cli: Document plugin naming convention

Created on 30 Mar 2018  路  4Comments  路  Source: vuejs/vue-cli

What problem does this feature solve?

There is a naming convention for third party plugin developers that doesn't seem to be documented anywhere (granted it's still in beta).

Also the fact that you can use invoke/add using shorthand. I could see users getting confused on whether or not @myscope/vue-cli-plugin-awesomeplugin and @myscope/awesomeplugin are the same thing. Not to mention that you can do vue invoke plugin if its an official vue-cli plugin.

I feel like requiring the explicit package name would be a lot better. It would be less confusing, there would be no need to document a naming convention and get issues about why something isn't working, and we would also be able to name our plugins wild esoteric things. Is there a strong reason for doing this? Or am I just misunderstanding something?

What does the proposed API look like?

No shorthand for vue invoke|add.

documentation

Most helpful comment

there would be no need to document a naming convention

You still need to name your plugin with the vue-cli-plugin- form or else things will break. Also your plugin won't appear in search. If the naming convention isn't well documented yet, maybe it's time to do it properly. 馃悎

we would also be able to name our plugins wild esoteric things

Sorry, this is not currently technically possible.

All 4 comments

there would be no need to document a naming convention

You still need to name your plugin with the vue-cli-plugin- form or else things will break. Also your plugin won't appear in search. If the naming convention isn't well documented yet, maybe it's time to do it properly. 馃悎

we would also be able to name our plugins wild esoteric things

Sorry, this is not currently technically possible.

Hey @ascendancyy ,

Here is another pointer :

At compile time, the vue cli runs through the dependencies to find the plugins.
It then adds webpackChained configurations for each plugin to the webpack configuration.
This allows plugin developpers to customize implicitly the webpack configuration without invading user files.

=> No prefixing plugins, no webpack configuration

The choice of abstracting the configuration is by design. It can be counter-intuitive at first but allows for better upgradability.

Hope this helps

Ah okay that makes sense. The package naming should definitely find its way onto a doc page though.

Closing as this is addressed in the refactored docs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

DrSensor picture DrSensor  路  3Comments

CodeApePro picture CodeApePro  路  3Comments

OmgImAlexis picture OmgImAlexis  路  3Comments

b-zee picture b-zee  路  3Comments

csakis picture csakis  路  3Comments