V2 addons' build-time integration

[NullVoxPopuli]

It's a common ask among all addon authors that augment "the build" that they don't want to push build config on to the consumer.

While there are tradeoffs for the current v2 addon approach (very explicit, push all complexity to consumer) and the current v1 addon approach (hide everything from the consumer), It'll be good to explore a path forward as we want all addons to be v2 addons (for eventually removing embroider's compat-layer, dramatically improving build speed).

There is https://github.com/unjs/unplugin
which allows plugin-authoring for many packagers -- and this is important because we don't want to be tied to webpack forever. For example, supporting Vite (or Mho) would give us all massive dev-time performance improvements (sub-second builds).

In order for a v2 addon to declare what build-time stuff it wants to provide, maybe we propose a static-config in the package.json that embroider can read and alter the packager config as appropriate.

For example,

// package.json
"files": [
  "dist", // addon code
  "lib", // node code
  "addon-main.cjs", // compat main
],
"ember-addon": {
  "version": 2,
  "type": "addon",
  "main": "addon-main.cjs",
  "plugins": [
    "./lib/my-custom-plugin.js"
  ]
}

specifically

  "plugins": [
    "./lib/my-custom-plugin.js"
  ]

which would point to a file, not a part of the actual addon (as v2 addons may not contain node code, as they are browser-runtime only). By convention seen elsewhere in the ecosystem, the lib folder would be the collection of node stuff that could be integrated into the build.

As a caveat, something v2 addons have been doing is specifying exports.
for example (from ember-resources):

"exports": {
  ".": "./dist/index.js",
  "./util": "./dist/util/index.js",
}    

This is how npm packages declare what is public api -- nothing else may be imported or required.

In order to support both browsers and node / plugin-augmentation would need to have something like this, instead:

"exports": {
  ".": {
    "import": "./dist/index.js",
  }
  "./util": {
    "import": "./dist/util/index.js",
  },
  "./lib/my-custom-plugin.js": {
    "require": "./lib/my-custom-plugin.js"
  }
}

As a caveat here, and open question, only embroider supports "import" -- if we did

  ".": {
    "import": "./dist/index.js",
    "require": "./dist/index.cjs",
  }

in non-embroider builds, the require entry would be used instead of the import -- which is kinda problematic -- but is more reason to switch to embroider...
I don't know if there is a way around that... but might be good to document / figure out.

personally, I'm ok with this proposed v2 addon feature only being available in embroider builds.

Additional thoughts / learnings from the old system:

• plugins should all augment the host app's build -- the v1 system of everything have a small isolated build per addon is immensely hard to work with, and I don't think we should continue with it.

Alternatives:

• we can provide easy code mod utilities for augmenting the host app's build files for users. like, addPublicTree() (to ember-cli-build.js), addPlugin(), etc -- which modifies the consumer app's ember-cli-build.js

[wagenet]

@NullVoxPopuli what sort of feedback are you looking for on this before writing a draft RFC?

[NullVoxPopuli]

if it's worth the effort - if someone is out there with motivation to implement it, what people think about adding to package.json, etc?

[wagenet]

I can't tell you for sure that it's worth the effort, but I can tell you that my goal is for all RFCs to actually get proper consideration and feedback in a timely fashion.

Whether there is motivation for anyone to implement probably should also be part of the RFC process. If the RFC is convincing, then people will see the benefits of the proposed change and desire its implementation. If, after seeing the RFC, everyone is still "meh" then that's honestly a good indicator that the RFC probably shouldn't get merged. I get that it would be nice to have this level of feedback before writing the RFC, but that isn't going to always be possible. Sometimes the idea is so obviously good that everyone agrees in advance, but other times people will need convincing. The very fact that someone is willing to put in the effort to write an RFC is a big step in this direction. If nobody is even up for writing an RFC then it's honesty unlikely that anyone will be up for implementing.

[NullVoxPopuli]

makes sense! I'll try to get this scheduled in during work, as I think my work has a solid use case for this.
(as does @mansona's fieldguide stuff)