lineman plugins to make use of npm run-script

[jasonkarns]

We currently have a set of plugins that expect a preconfigured directory structure. The directory setup is provided by the various linamen-*-template repos, but I think this can be improved.

What if the directory structure setup could be done via a plugin's script? So, for example, the lineman-angular plugin could have a configure or setup script in its package.json. It could create (if they don't already exist) the js/{controllers,directives,resources,services} directories and js/{app,router}.js files.

It would be executed as npm run-script lineman-angular configure.

Thoughts?

[searls]

I made a note to do this in the spec-browser plugin but I opted to hold off ( https://github.com/linemanjs/lineman/issues/212 ). I also added an npm install script to lineman-bower which generates a .bowerrc for the user. 

On one hand, it'd make setup easier in some cases. On the other hand, I abhor code generation when it's anything but a minimal instruction. The garbage that rails generators litter throughout your project (leaving the user both less sure of the code base and less able to upgrade) has just really soured me to the idea. 

Another important consideration here is whether installing a plugin later in a project's life might inadvertently cause a headache with files unhelpfully generated in the wrong place. 

I've been thinking about this a lot lately and I'm still not sure of a good approach. I like the idea of opt-in, but it'd have to be discoverable or the people who need it most won't find it.

[jasonkarns]

Yeah, I definitely don't think it should be part of the automatic npm-install lifecycle. That comes with so many headaches we'd be better off avoiding. Making it a general purpose configure or setup script means it would only be run manually (as far as npm were concerned).

However, coupled with #218, the fact that it's a manual script rather becomes moot since it would be automatic within the context of lineman. It would be cool if it were discoverable, but I'd only see that as a bonus.

And – even though I think discoverability is secondary – a quick win would be to have an install script that spit out a message indicating that a configuration script were available. But that's a separate discussion.

Lastly, I would aim to make these scripts solely about directory and file structure. I would keep code generation to an absolute minimum, if at all.

[searls]

👍

On Sun, Feb 23, 2014 at 3:05 PM, Jason Karns [email protected]
wrote:

Yeah, I definitely don't think it should be part of the automatic npm-install lifecycle. That comes with so many headaches we'd be better off avoiding. Making it a general purpose configure or setup script means it would only be run manually (as far as npm were concerned).
However, coupled with #218, the fact that it's a manual script rather becomes moot since it would be automatic within the context of lineman. It would be cool if it were discoverable, but I'd only see that as a bonus.
And – even though I think discoverability is secondary – a quick win would be to have an install script that spit out a message indicating that a configuration script were available. But that's a separate discussion.

Lastly, I would aim to make these scripts solely about directory and file structure. I would keep code generation to an absolute minimum, if at all.

Reply to this email directly or view it on GitHub:
#217 (comment)

[jasonkarns]

Thoughts on the script name? configure, setup, scaffold, template,
other?

I think configure and setup convey too much expectation that it will
muck with configuration settings (which it won't).
template is already overloaded within a frontend project, but it mirrors
the result (that the directory will approximate the associated
lineman-*-template).
scaffold might be the most appropriate, but carries the most baggage.

All options being terrible, what's the least bad?

[searls]

Let's sit on it. I'd rather find something less well worn.

On Sun, Feb 23, 2014 at 3:11 PM, Jason Karns [email protected]
wrote:

Thoughts on the script name? configure, setup, scaffold, template,
other?
I think configure and setup convey too much expectation that it will
muck with configuration settings (which it won't).
template is already overloaded within a frontend project, but it mirrors
the result (that the directory will approximate the associated
lineman-*-template).
scaffold might be the most appropriate, but carries the most baggage.

All options being terrible, what's the least bad?

Reply to this email directly or view it on GitHub:
#217 (comment)

[davemo]

@jasonkarns has this been sat on enough? is it still relevant? needs more sitting? :D

[jasonkarns]

npm run-scripts no longer support invoking a script of a dependency as they once did.