Ignite: Allow custom prefixes for ignite plugins because of reasons

Created on 11 Oct 2018 · 4Comments · Source: infinitered/ignite

Dear Ignite team,

recently I built a boilerplate based on your awesome Ignite CLI. I did not use the command line to initiate it but rather forked a different project.

The main focus was custom generators to support a certain file structure.

To my surprise, after adding the plugin in a project, the command line showed the correct generators but with missing descriptions. Also the generators failed silently. Apparently some data from the plugin was picked up correctly but it did not work. What was happening?

Turns out, when generating a plugin, the CLI prefixes its name with ignite-, which is then the package.json name, as outlined here. But his prefix is also a _requirement_ for the plugin to work at all, because when I added it on a whim to my plugin's name - it worked!

This in itself is not much of a problem, merely a small documentation improvement.

But where a problem arises is in the case of scoped npm packages:

Creating a New Scoped Package
To create a new scoped package for your Organization scope, create a directory with the name of the package you would like to create. Navigate into that directory and use this command:

npm init --scope=<org_scope>
To verify that this worked, open the generated package.json with an editor of your choice. You should see that the name of the package will be @org_scope/<pkg_name>.

So if I want to publish an npm package for my organization, wether it be public or private, it can not be done for Ignite plugins, because of the must-have ignite- name prefix requirement.

I would very much like to manage distribute my Ignite plugins for internal use via npm, that's why I would like to ask for a change in the CLI to make this possible.

bug released

Source

monotv

👍2 ❤1

All 4 comments

Absolutely, this is a valid concern. Thanks for bringing it up @monotv !

Do you have a sense for how we might accomplish this? Simplest is probably just to detect the @ at the beginning of the string and don't make any changes to the name.