Refactor blueprint

[MajorBreakfast]

See discussion below.

[stefanpenner]

This change seems to be a step in the wrong direction.

I would prefer to have a blueprint object and a fileinfo object that encapsulates this complexity and clearly explains intent.

[MajorBreakfast]

It doesn't hold any state?

[stefanpenner]

it encapsulates complexity, and maintains the blueprint sessions state.

Churn for the sake of churn really causes a lot of un-needed noise.

[MajorBreakfast]

What session state? The blueprint is a folder with a bunch of files. I'd really like to keep it that simple.

I rewrote it because I didn't understand the old version. Isn't it much easier to understand now?

[stefanpenner]

I don't believe so.

State includes dependency instances. Entities should not have explicit dependencies on there collaborators, this just becomes unmaintainable. A solution for this is injected a dependency during entity construction. Then these collaborator instances are available at runtime, following this approach continues to decouple our project and also simplify testing.

When fixing something, the smallest amount of refactoring to facilitate the fix is appropriate, or submit a refactoring first.

[MajorBreakfast]

Hmm I don't get it. What dependencies are you talking about. Could you explain this in simpler terms? What do you mean by a collaborator?

My concept:
Tell blueprint task the blueprint folder -> prompts user if there are conflicts -> copies files into cwd

I don't care whether we use this version. Main problems with the old one are:

• It's output doesn't go through ui all the time Edit: Patched in ui.prompt with inquirer #411
• It's output is verbose even if --verbose wasn't specified
• It's code is twice as long and complicated as it needs to be

[stefanpenner]

checkout the command refactor to see what i mean by collaborator. As that is finished I'll update the arch doc accordingly.

I believe the code can be improved, but I also believe you have not noticed all the functionality. Such as: Prompting the user each question first, and later batch applying.

Additionally a Blueprint is a "real thing", it has collaborators, it carries the state of the current session. Additionally, we plan to use this constructor for our generators.

I am very fine with improving the current constructs, but not to disembody them.

[MajorBreakfast]

#411 now fixes the tests on windows an pimps ui.prompt(). So that's no longer part of this PR. But I still think that the blueprint code needs some love. Before I continue its refactoring, though, I want to discuss it some more first.

#377 (comment) pretty much summarizes of what I think of the current blueprint implementation.

The flow I describe there:

• Tell blueprint task the blueprint folder
• Then: Prompt user to resove conflicts
• Then: Copy files into cwd

I want some convincing comments on why moving all blueprint related stuff into the install-blueprint task isn't sensible. I think that lib/blueprint.js and lib/models/file-info.js are a mess :)

[MajorBreakfast]

I'm closing this.

We plan to unify generators with the blueprint. The blueprint we have now would then only become another generator. #351