WarpDrive: A framework-agnostic build plugin for WarpDrive - #1233
WarpDrive: A framework-agnostic build plugin for WarpDrive#1233runspired wants to merge 1 commit into
Conversation
Proposes replacing WarpDrive's babel-based build configuration (@embroider/macros + setConfig wiring) with a single unplugin-based bundler plugin imported from @warp-drive/core/build-plugin, working across Vite, Rollup, Rolldown, Webpack, Rspack, and esbuild for Ember, React, Vue, Svelte, and Angular apps. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AVxFCVeSYADB6iPtnnQJUR
runspired
added
T-ember-data
| else): | ||
|
|
||
| 1. **Published WarpDrive packages.** WarpDrive's published code carries its flags as | ||
| `@embroider/macros` expressions (`macroCondition(getGlobalConfig().WarpDrive...)`). The |
There was a problem hiding this comment.
we have 2 options here:
-
we would maintain the published version using @embroider/macros statements until the existing babel config approach is deprecated and removed
-
since the babel config uses a util imported from warp-drive, we could swap it to process these via a babel-shim for the new plugin and migrate our publishing format to something with zero risk of confusion for @embroider/macros
| `@embroider/macros` expressions at all, switching to plain flag imports with working runtime | ||
| defaults — at which point a build with no plugin configured still runs correctly (as an | ||
| unoptimized development-flavored build that logs a one-time warning), and `@embroider/macros` | ||
| leaves WarpDrive's dependencies. |
There was a problem hiding this comment.
once this is achieved, WarpDrive itself can simplify its own build process,
- drop the build-config package (remaining code can just move into core since core will no longer need a prebuilt plugin to build itself)
- all library builds can drop the babel step maintained purely for converting boolean imports into macros statements for publish.
| During migration, an app may have both the plugin and an embroider babel pass wired. This is | ||
| safe in both orders: | ||
|
|
||
| - The plugin runs ahead of babel (`enforce: 'pre'`). After it transforms a WarpDrive file, no |
There was a problem hiding this comment.
note we don't need pre if we opt to move away from publishing embroider/macros statements immediately
| ...Macros.babelMacros, | ||
| // ...decorators, templates, etc. | ||
| ], | ||
| }; |
There was a problem hiding this comment.
we should also show the migration of the currently recommended shorthand
| temporarily get identical output (same config, either order) or a loud conflict error if the | ||
| two ever disagree — never silent divergence. | ||
|
|
||
| Classic ember-cli apps migrate by doing nothing: `setConfig(app, __dirname, config)` is |
There was a problem hiding this comment.
if we were to shift off of embroider/macros as our publishing format, classic apps would necessarily need to either add a new thing into their build (updated babel plugin perhaps) or move off of the classic build system.
|
|
||
| ## Unresolved questions | ||
|
|
||
| - The classic ember-cli story at 6.0 relies on the addon automatically injecting the babel |
There was a problem hiding this comment.
another unresolved q: whether the under-development AQL and DSL build plugins ought to be combined into this. It's less clear that's possible due to how they produce virtual imports from directory and file scans.
2 participants
Proposes replacing WarpDrive's babel-based build configuration (@embroider/macros + setConfig wiring) with a single unplugin-based bundler plugin imported from @warp-drive/core/build-plugin, working across Vite, Rollup, Rolldown, Webpack, Rspack, and esbuild for Ember, React, Vue, Svelte, and Angular apps.
Propose WarpDrive: A framework-agnostic build plugin for WarpDrive
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP