Maintaining this long-term by splitting it up

[erikjung]

@lyzadanger @tylersticka

I had some ideas about how to make this more maintainable when used on real projects going forward.

It seems that we're in agreement that un-forking is inevitable. But beyond that, I think we might see some benefit in splitting the tool into smaller pieces. I see it broken down as:

• The Assembler (fabricator-assemble)
• The Fabricator CSS/HTML
• Gulp tasks
• Template helpers

The first one, fabricator-assemble, is already modular enough since it's a Node package. We don't own it or have to maintain it. I think we can convert the other items into Node packages as well. The outcome would be that new pattern library projects would only consist of unique HTML, CSS and JS:

new-project/
  assets/
    styles/
    scripts/
  data/
  materials/
  node_modules/
    fabricator-assemble/
    cloudfour-fabricator-ui/
    cloudfour-fabricator-tasks/
    cloudfour-fabricator-helpers/

I don't know how we should approach this quite yet, but our source seems flexible enough to support it. I'll have to experiment a bit to find out how feasible this approach is. Thoughts?

[tylersticka]

That sounds nice to me. I don't feel knowledgable enough to passionately proclaim This Is What We Must Do, but your thinking makes sense to me.

[lyzadanger]

Some thoughts:

Can you expand on the cloudfour-fabricator-ui bit? At first blush it feels like an awkward fit for an npm module, unless it were one installed globally—that is, the stuff in there feels more like scaffolding than a local node_module, like, something yeoman or similar is cut out to handle, though I have limited exposure to those design patterns. It may make sense to have some of the initial project directory structure (assets, data, materials, etc.) could be skeleton-ed out by this generator/scaffolding?

I'm trying to also square myself with the argument for splitting the UI from the (gulp) tasks. Can the two really exist independently? What is the context for the cloudfour-fabricator-ui module/chunk without the cloudfour-fabricator-tasks module? Or vice versa?

Regarding cloudfour-fabricator-helpers, are the helpers specific to fabricator builds or are they useful Handlebars helpers overall (or a mixture of both)?

I'm trying to tease out various interdependencies here. I like the idea of modularization, but if all of the modules (except for the third-party fabricator-assemble) are co-dependent on each other, does it make sense?

I may do a little research on scaffolding/generator options these days...

[lyzadanger]

I spent some time thinking about this and I have a few ideas, but they warrant a with-voices conversation. Maybe chat about this sometime soon?

[erikjung]

Can you expand on the cloudfour-fabricator-ui bit? At first blush it feels like an awkward fit for an npm module, unless it were one installed globally—that is, the stuff in there feels more like scaffolding than a local node_module, like, something yeoman or similar is cut out to handle, though I have limited exposure to those design patterns.

I think it could be just the Fabricator-specific styles, partials, and script(s). Consider these directories:

• https://github.com/cloudfour/fabricator/tree/dev/src/assets/fabricator
• https://github.com/cloudfour/fabricator/tree/dev/src/views/layouts/includes

These files make up most of the Fabricator UI, and are also pretty distinct from the rest of the source code. It seems feasible to package them in some way that is more self-contained.

It may make sense to have some of the initial project directory structure (assets, data, materials, etc.) could be skeleton-ed out by this generator/scaffolding?

I also like the idea of using something like a Yeoman generator for this. I also lack familiarity with that particular tool :) That might be a better fit overall. We could still keep the generator/files versioned separately. We can call it generator-fabricator-fabricator (j/k)

Regarding cloudfour-fabricator-helpers, are the helpers specific to fabricator builds or are they useful Handlebars helpers overall (or a mixture of both)?

Useful overall, or else we're probably doing template helpers wrong.

I spent some time thinking about this and I have a few ideas, but they warrant a with-voices conversation. Maybe chat about this sometime soon?

Of course. Lots to consider, but I think it's doable.

I think the Gulp tasks would be the easiest. As long as the configuration can be passed in differently. Here is some WIP on that idea: https://github.com/cloudfour/labs/tree/master/scaffolding/gulp-website/build/tasks

Example:

/**
 * All assumptions:
 * - The existence of conf.src
 * - The existence of conf.dest
 * - The possibility of env.dev
 */
module.exports = function (conf) {
  gulp.task('css', function () {
    return gulp.src(conf.src)
      .pipe(postcss([
        importer(),
        cssnext()
      ]))
      .pipe(gulpif(!env.dev, cssnano()))
      .pipe(gulp.dest(conf.dest));
  });
};

Main point: the tasks can be modular if they don't need to require() their configuration.