-
-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V2 addons' build-time integration #829
Comments
@NullVoxPopuli what sort of feedback are you looking for on this before writing a draft RFC? |
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? |
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. |
makes sense! I'll try to get this scheduled in during work, as I think my work has a solid use case for this. |
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,
specifically
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):
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:
As a caveat here, and open question, only embroider supports "import" -- if we did
in non-embroider builds, the
require
entry would be used instead of theimport
-- 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:
Alternatives:
addPublicTree()
(to ember-cli-build.js),addPlugin()
, etc -- which modifies the consumer app's ember-cli-build.jsThe text was updated successfully, but these errors were encountered: