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 think generally the RFC needs more prose explaining the goals of the blueprint and less of the specifics of files.

It probably needs more of the documentation that we need to write anyway about how to use a v2 addon blueprint to build or upgrade an addon.

[kategengler]

Blueprints are living. The specifics of files within this document may quickly become irrelevant. I think the RFC in general should talk more about the goals of those configurations than the details.

I also propose we add parallel .md files to the blueprint explaining config files and setup. Comments could also work but would potentially cause conflicts on updates. We could also offer and opt-out to not generate them.

[kategengler]

Without context, this argument only makes sense if you were around for the iteration of the v2 addon.

[void-mAlex]

if we add an export for ./src/*.gjs we can make local dev work with self import style
the tests would just need to import with an extension set
it's also something I would love to see in the default bp for private addons that don't need to publish
if this goes forward without that support it would be a major loss over v1 addons that it would need to be built in a separate terminal when working on any consuming app

[ef4]

 if this goes forward without that support it would be a major loss over v1 addons that it would need to be built in a separate terminal when working on any consuming app

Local addons that don't need a build of their own are a legit use case, but it definitely needs to be distinct from the defaults for a publishable addon. They want to be quite different. It's either a flag or an entirely different blueprint.

In particular, a non-built addon should drop a huge chunk of all the devDeps.

if we add an export for ./src/*.gjs we can make local dev work with self import style

Unfortunately package.json exports rules don't allow any fallbacks, so if you put .gjs in the exports explicitly it's the only extension that works with an extensionless import. It's usually better to leave the extension search up to your build tool. An app building with vite with a local addon that has ./src/* in exports will search and find both .js and .gjs.

[ef4]

RFC should probably explain what to do about in-repo addons.

You can make v2 ones, if you use your package manager to establish them as real package dependencies. They probably want to be "unbuilt" ones.

[void-mAlex]

if we add an export for ./src/*.gjs we can make local dev work with self import style

Unfortunately package.json exports rules don't allow any fallbacks, so if you put .gjs in the exports explicitly it's the only extension that works with an extensionless import. It's usually better to leave the extension search up to your build tool. An app building with vite with a local addon that has ./src/* in exports will search and find both .js and .gjs.

should we just use an alias in vite config to point addon name imports to the source files?
then leave broken import maps config out of package json; and have build just point to dist as it should?

[NullVoxPopuli]

NOTE: ember-cli currently does not like when addons specify custom arguments, and prints a warning whenever they are used.

This should be fixed in ember-cli, as we've needed this (and used this) behavior in blueprints for several years now.

Not a blocker for this RFC

[kategengler]

iirc that is a side effect of whatever ember-cli is using for arguments; I agree we should fix it but blueprint flags do need to be "known" by ember-cli-update, at least.

[NullVoxPopuli]

they're only "known" at all because of what's in the ember-cli-update.json, yea?