Discussion: Multiple builder archetypes

[ryan-roemer]

Let's start this as a brainstorm for supporting multiple builder archetypes

Questions

• [ ] Do we want multiple archetypes supported?
  • (I'm assuming so, would be nice to split up client test / server test / build / etc.)
• [ ] How do we order overrides in archetypes?
• [ ] Would multiple archetypes potentially need to "combine" script commands?
  • [ ] Strawman idea: Have a builder add command that acts normally like run, but when traversing something like archetype1:package.json:scripts:test = "builder add foo" and archetype2:package.json:scripts:test = "builder add bar", when run from project it would be effectively test: "builder run foo && builder run bar".

Sample Scenario

# ROOT/.builderrc
archetypes:
  - archetype1
  - archetype2

# node_modules/archetype1/package.json
"scripts": {
  "foo": "echo foo",
  "test": "builder run foo"
}

# node_modules/archetype2/package.json
"scripts": {
  "bar": "echo bar",
  "test": "builder run bar"
}

So, builder run bar and builder run foo work just fine, but builder run test needs a priority / override resolution of some type...

/cc @chaseadamsio @exogen @kenwheeler @boygirl

[boygirl]

It would be nice to compose archetypes, but it sounds like it could get ugly really fast since each archetype will be assuming (or creating) a specific file structure. How do we detect and reconcile incompatible archetypes? I also do like the simplicity of having the entire "recipe" for a project all in once place.

[curiouslychase]

+1 @boygirl's simplicity point.

@ryan-roemer of all the questions in the initial brainstorm, how many have we actually encountered so far? Are you guys getting to a point where these are true pain points?

[ryan-roemer]

@boygirl @chaseadamsio -- Here's my background of thinking: Next up is a builder-react-app archetype for converter-react.

The frontend test, lint stuff will be virtually identical to builder-react-component. So, hence "should we combine"?

And to be clear, the answer may well be no we should not combine. (Maintaining parallel archetypes with duplication is not really that big of a deal vs. parallel projects).

[boygirl]

@ryan-roemer I vote for keeping the simple approach. I think it will naturally force us to keep a small number of complete, well-maintained archetypes. It's not as flexible as what you're suggesting, but I actually see that as win for enforcing consistency and standards across projects.

[curiouslychase]

Totally agree with @boygirl.

[exogen]

I like the goal of keeping it simple and think we should keep it that way for now.

But I can see why building up archetypes piecemeal is desirable, especially as we use Builder more and more. Here's a scenario: we have a repo like victory-util where there's no actual React component, just a bunch of helpers. But we migrated it to use builder-react-component because we wanted everything else that comes with that archetype – webpack, Karma, eslint, etc. Thankfully the missing component part didn't cause any errors – but it could have!

Let's say we had an archetype that just got you the linting/testing bits. If archetypes weren't built up piecemeal and you could only have one, then we'd need to keep the builder-lint-test-archetype in sync with builder-react-component (which also has linting/testing bits). (Side note: would builder-react-component be able to depend on builder-lint-test-archetype? So you still only need one archetype in builderrc, but that archetype could be composed of others?)