A quick update on this:

  1.  I've modularized the generator into:
     *   main generator that does the "core" setup (package creation + linter)
     *   A "clientGrade" subgenerator for generating client-side grades and 
        *   An "all-tests" subgenerator for generating the client-side 
"all-tests" file

I'd still consider this alpha-status work, but if others want to experiment 
with it by adding additional subgenerators, it is now in a better state to do 

From: fluid-work 
 on behalf of Alan Harnum <ahar...@ocadu.ca<mailto:ahar...@ocadu.ca>>
Date: Tuesday, August 1, 2017 at 10:15 AM
To: Tony Atkins <t...@raisingthefloor.org<mailto:t...@raisingthefloor.org>>
Cc: Fluid Work <fluid-w...@fluidproject.org<mailto:fluid-w...@fluidproject.org>>
Subject: Re: Yeoman generator for Infusion projects

Hi Tony,

I'm still learning about how Yeoman does things, but I think these two pieces 
are relevant to your question:

Composability (http://yeoman.io/authoring/composability.html) allows generators 
to run other generators. So we could conceive of a structure like the following:
- generator-infusion

Sub-generators lets you have additional generators under one generator, to let 
you run commands like "yo infusion:client" and scaffold a client-side component 
or similar, a la "rails generate". It feels like Yeoman is de-emphasizing these 
features since its recent rewrite and encouraging a focus on composability / 

AFAICT a "generator" is simply the Yeoman convention for packaging a set of 
template files and instructions for rendering them after taking input from the 
user, along with other actions like running npm install, etc. They don't 
conflict with each other unless they write files with the same name to the same 
location or similar, so it's perfectly safe to run multiple generators in the 
same directory when scaffolding – I believe this is expected usage to enable 
the generation of boilerplate files based on input (instead of the cruder, 
slower "code generation" of copying and pasting files / file contents).

I'll have a go at separating the current work into a "core" and a "client" 
generator to see how that goes, and will be in a better position to discuss 
composability / inheritance then.

From: Tony Atkins <t...@raisingthefloor.org<mailto:t...@raisingthefloor.org>>
Date: Tuesday, August 1, 2017 at 3:51 AM
To: Alan Harnum <ahar...@ocadu.ca<mailto:ahar...@ocadu.ca>>
Cc: Fluid Work <fluid-w...@fluidproject.org<mailto:fluid-w...@fluidproject.org>>
Subject: Re: Yeoman generator for Infusion projects

Hi, Alan.

Fantastic effort, thanks for getting this started.  Can you talk for a bit 
about template inheritance, i.e. whether we can create a "core" template and 
then overlay a "client" and "node" template on that?  I'm really interested in 
helping create the "node" template, just want to get a rough idea of how we 
might do that without duplicating bits of boilerplate unnecessarily.



On Mon, Jul 31, 2017 at 3:51 PM, Harnum, Alan 
<ahar...@ocadu.ca<mailto:ahar...@ocadu.ca>> wrote:
Shared for possible interest to the community, an initial stab at an Infusion 
scaffolding generator for Yeoman (http://yeoman.io/): 

I rolled this after realizing how many steps I had to get a full proper setup 
for developing a new project (linter configuration, initial file structure, 
etc). Right now this is purely front end - if there is community interest I can 
continue to put occasional development time into this as I have spare cycles.


E ahar...@ocadu.ca<mailto://ahar...@ocadu.ca>

100 McCaul Street, Toronto, Canada, M5T 1W1

fluid-work mailing list - 
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Reply via email to