It seems to me that the 'plugin' in this case, is simply a baseline docker image plus sample syntax for how to run a command within it that is otherwise identical to a Freestyle step. All of the work of installing the script in package.json and telling the plugin which command to run is still an exercise for the user. All that's required is a docker image with npm (or the npm client of your choice) and you can do the same thing in a Freestyle pipeline step without any syntax changes.

Wouldn't it be more useful to just have a plugin for running npm-based steps, which provides a codefresh-approved npm environment (which should probably have npm, yarn, and lerna all installed, plus node), and then instead of specifying the entire npm command in the commands list, allow the user to just specify the name of the scripts that should run plus any parameters. The actual npm client can be specified in package.json. The syntax would be more like this:

npm_step:
title: Running something via npm
image: codefresh/npm-tools
token_var: NPM_TOKEN
commands:
- build --production
- prerelease --production
- release

The plugin would then know how to structure the npm commands, including the addition of the npm token via the var that was specified. Otherwise, i don't see much difference between the 'plugin' and a Freestyle step with identical syntax, other than the type of the step.

In my example, I can set my npmClient to be yarn in package.json. And if I use lerna to update versions and push npm packages, I can set up a 'release' script which calls 'yarn run lerna publish.' Even so, it's about the same number of lines of code whether using the plugin or just running a Freestyle step, so there doesn't seem much value in the re-usable component. A naive npm user may not realize how easy it would be to add commands other than release-to-npm to such a step, for example.