v2 addon by default

[NullVoxPopuli]

rendered

[kategengler]

Would like to codify a testing story where Ember used as library without having to have a separate app.

[NullVoxPopuli]

TODO:

• explain how to have a v2 addon in a monorepo that doesn't have a build -- an unpublished addon (exports etc changes)
• sync with @ember/addon-blueprint
  • add information about the demo-app
  • explain compat-modules (pending bugfix in embroider)
    • for both demo app and test-app
  • explain when to think about importing from sub-path imports, vs importing "like a consumer would"
  • babel configs
  • remove resolve.alias from vite config
  • glint2 is no longer alpha
    • glint object in tsconfig no longer needed
    • remove glint imports from unpublished-development-types
• move babel.config to esm
• update eslint.config (RFC at the time of writing this comment is using a deprecated API)

[kategengler]

I'm in favor of moving this RFC forward.

We needed a v2 addon by default years ago. Today, users who follow the guides and use ember-cli directly are generating v1 addons by default which is a terrible situation when the app format is v2 by default.

The addon blueprint will of course continue to evolve, as it has for years; we do not need to determine every detail of the most perfect developer experience because what we have now is still massively better than what users get today when generating an addon.

Accepting the RFC is a signal to the community that this is happening. There is plenty here we can begin to work on: integration with ember-cli, changes to ember-cli-update, documentation.

[mansona]

I've gotten a chance to start reviewing this RFC as written today and It's really not ready to move forward to acceptance and needs to be rewritten. There are parts of this that don't make sense, there are way too many unrelated topics, and there are assertions that cannot ever be true.

For example, the section about removing the release train is not something that can fly at all and is completely unrelated to this RFC.

@kategengler I'm surprised you want to move forward with this RFC with sections like that in there 🤔 Was it something that you missed, or am I missing a conversation that was dismissed or deleted somehow?

I propose that we remove the FCP label for now and I will commit to getting a rewrite/restructure PR by the end of next week 👍

[NullVoxPopuli]

What specific things make this not ready to be move forward "and need to be rewritten"?

removing the release train

there seems to be some misalignment here, because it's my understanding that we already want all blueprints not to follow the release train at all, and just use the previously discussed pinning / ~ convention for what ember-cli uses -- so much so that when I opened an RFC to propose the details of this in writing, people were like, RFC not needed, we already want this, and it's a temporary problem that the blueprints are tied to the release train at all.

I will commit to getting a rewrite/restructure PR by the end of next week 👍

why is it you need to rewrite/restructure?
I'd like to know what is wrong so I can improve

[NullVoxPopuli]

Reminder for reviewers of this rfc:

• glint v2 only supports gjs/gts (no hbs)
• glint v2 is default in the ember extension pack
• glint v2 is default in the v2 addon blueprint
• supporting hbs (or rather, anything not currently working) is bugfix territory with the v2 addon blueprint
• users who need hbs can use glint v1, but there is basically no capacity no support glint v1 right now (for a lot of reasons that i can get in to later when not on my phone)

[kategengler]

I'm surprised you want to move forward with this RFC with sections like that in there 🤔 Was it something that you missed, or am I missing a conversation that was dismissed or deleted somehow?

@mansona This was discussed in a few meetings. We established that we didn't expect the blueprints to follow the release train necessarily but that we also expected tools like ember-cli-update to continue to work and for each version of ember-cli to know what version of the blueprint it should use. The rest is implementation details.

I've read this RFC multiple times as it iterates.