Merge ember-cli-create into ember-cli / Configuration Authoring Format

[gossi]

At Emberfest 2018 I demoed ember-cli-create.

You can find the video here: https://www.youtube.com/watch?v=mZD0aaf3IoA

Of course it is my pleasure to at some point merge it back into ember-cli itself. Also based on the feedback I received it is admired very hearth welcoming.

I thought I put together what I see needed to nail the merge and truly make benefits of the concepts that come with it. Most of them I outlined in my blog post: Thoughts on Improving Developer Ergonomics for emberjs.

First make yourself comfortable with the lengthy but great embroider spec by @ef4. He is talking about the the publication format for packages while I describe the authoring format in my blog post. One problem described from different angles and with ideas for solution. I think a new authoring format can be worked out (given it will receive a different filename) and people can opt-in to the new format by creating the new file (the old one will then be ignored). Despite working out a structure for a new authoring format, it's also to define what blueprints and presets are (hint: I see presets as a way to parametrize blueprints), these configuration in presets need a slot in the authoring format to be docked into.

Second is to run more research on what categories the ember-cli-create wizard will take. That can happen with the current addon (I have several ideas) for the time being.

A summary on a very high level:

• Work out an authoring format
•  Define blueprints and presets
•  Implement new authoring format
•  Research the UI wizard for ember-cli-create

[stefanpenner]

First of all, ember-cli-create is pretty cool, good job!

Don't take my following tone as negative, I simply want to manage expectations, ensuring that no surprises so that we can all work together to ensuring our tooling continues to improve.

---

From reading, these appear to be two different issues, and the discussion should likely be split:

1. ember-cli-create
2. embroider

It's not clear to me why they are being coupled into one issue. Both will require a full and independent RFC process, and are not coupled, as embroider can utilize the existing -t blueprint solution to provide it's proposed/future functionality.

If embroider is successful, it will become the default until then -t will suffice, thus not requiring a wizard to select it.

---

re: ember-cli-create, although wizards can be helpful, they pose a high maintenance/support/compatibility/upgrade cost. Those issues can likely be addressed, but will require design. If we are to consider a "choose your own adventure" wizard such as ember-cli-create, that design will need to be put forward.

Areas it will likely need to cover (in RFC):

• ensuring the matrix of possible builds are do not break, and do not balloon test times
• ensuring the upgrade path/docs/guides/diffs are friendly to the matrix of possible builds
• ensuing the ember-cli core team's ability to iterate is not embedded.

If a wizard approach is added, it should likely be done so via https://github.com/ember-cli/blprnt (which would love another maintainer ;))

[gossi]

Thanks @stefanpenner - there absolutely two parts invovled here, thanks for pointing out those directions. Consider this issue as a meta/quest thing then.

PS. I mainly put this up mainly, because I now can link to this issue when people ask me =)

[kellyselden]

We chatted about this on a call a few weeks back. We all agreed ember-cli-create was a great project, and we would be very interested in using its wizard style for our existing options (yarn, welcome screen, etc). When we started talking about bundling third party stuff like less, composable helpers, etc, veryifying they always work in different combos, avoiding one person bus factors, the maintenence burden seems really big and I'm not convinced yet we should do it. I currently think it existing in user-land is a good place for it.

If this does become an RFC, I'm curious:

• has vue-cli had any issues supporting this?
• is it worth stretching our maintence time across all configs instead of making sure a base app works great?
• how are projects like ember-cli-update going to adapt when no two projects start out with the same base app
• do we risk bundling ecosystem addons, or do we require they hand over their keys to us?

[stefanpenner]

@kellyselden ya, good summary.

[bertdeblock]

Going to close this because we accepted emberjs/rfcs#638. Implementation: #9824.