rfcs
rfcs copied to clipboard
Advance RFC #0763 `"Asset Import Spec"` to Stage Ready for Release
Advance #0763 to the Ready For Release Stage
Summary
This pull request is advancing the RFC to the Ready For Release Stage.
- PR to Accepted Stage: #0763
An FCP is required before merging this PR to advance.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Released Stage.
Ready for Release Stage Description
This stage is complete when the implementation is complete according to plan outlined in the RFC, and is in harmony with any changes in Ember that have occurred since the RFC was first written. This includes any necessary learning materials. At this stage, features or deprecations may be available for use behind a feature flag, or with an optional package, etc.
For codebase changes, there are no open questions that are anticipated to require breaking changes; the Ember team is ready to commit to the stability of any interfaces exposed by the current implementation of the feature.
This stage should include a list of criteria for determining when the proposal can be considered Recommended after being Released.
An FCP is required to move into this stage.
Each Ember core team will be requested as a reviewer on the PR to move into this stage. A representative of each team adds a review. If a team does not respond to the request, and after the conclusion of the FCP, it is assumed that the release may proceed.
Checklist to move to Ready for Release
- [ ] Implementation is complete according to plan outlined in the RFC, with any adjustments noted in the RFC
- [ ] Any necessary learning materials have been updated
- [ ] The Ember team is ready to commit to the stability of any interfaces exposed by the current implementation of the feature. This is the go/no go decision for any feature flags, but the flags should only be turned on when moving to Released.
- [ ] Criteria for moving to the Recommended Stage has been filled out
- [ ] This PR has been converted from a draft to a regular PR and the
Final Comment Periodlabel has been added to start the FCP - [ ] Each team has been added as a reviewer to the PR at the start of the FCP. Reviews are not required by the end of the FCP. This is a notification step.
- Framework @emberjs/framework
- Data @emberjs/ember-data-core
- CLI @emberjs/cli
- Learning @emberjs/learning-core
- Typescript @emberjs/typescript-core
- Steering @emberjs/steering
Criteria for moving to Recommended (required)
A set of criteria for moving this RFC to the Recommended Stage, following release:
- The "How we teach this" section of the RFC links directly to the required documentation updates.
- Update tutorial to use this feature for static images, etc.
- Update ember-welcome-page as a useful example.
Track Implementation
- [ ] Working implementation in embroider.
- [ ] Working implementation in classic builds (using ember-auto-import).
Leaving a few links here covering support status across the JS ecosystem as relevant to us:
- https://github.com/vitejs/vite/issues/14500
- https://github.com/vitejs/vite/discussions/14405
- https://github.com/webpack/webpack/issues/16693
- https://github.com/evanw/esbuild/issues/2866
Tl;dr: it's on people's minds, but nothing available and it seems nobody is actively working on it! 😟
Leaving a few links here covering support status across the JS ecosystem as relevant to us:
- Support
import.meta.resolve(…)vitejs/vite#14500import.meta.resolvesupport vitejs/vite#14405- Support import.meta.resolve webpack/webpack#16693
- Support for
import.meta.resolve(...)evanw/esbuild#2866Tl;dr: it's on people's minds, but nothing available and it seems nobody is actively working on it! 😟
I don't use Ember JS, but as someone involved with those issues I'm really glad to see activity here!
I'd be happy to advise or help out, as it would be extremely valuable for me as a library author to have support in the major bundlers (or anything else that resolves an import graph).
As covered in https://github.com/emberjs/rfcs/pull/763/files import.meta.resolve(…) was specifically designed with clear semantics that bundlers could us, and has been widely supported by all runtimes for a while now. It is also practical to rewrite to new URL(…, import.meta.url) for older browsers and runtimes. So I think it's definitely as good a time as ever to start supporting it.
I notived the PR doesn't mention TypeScript. I assume if someone is using TypeScript with Ember, they'd be able to resolve to .ts files just like .js files in the import graph?
Implementation projects:
- ember-auto-import needs a relatively small feature
- @embroider/vite: vite doesn't have out of the box support for import.meta.resolve but has the right semantics on
new URL(..., import.meta.url), so we can either rewrite to that or help upstream a PR supporting the other syntax - @embroider/webpack: would get the same feature implementation as ember-auto-import
I don't use Ember JS, but as someone involved with those issues I'm really glad to see activity here!
@lgarron yeah, same, thanks for raising those issues, let's join forces where we can! If you need people to voice support for upstream changes, we do have quite some standards-loving people here! 😅
I notived the PR doesn't mention TypeScript. I assume if someone is using TypeScript with Ember, they'd be able to resolve to .ts files just like .js files in the import graph?
The RFC here is specifically for resolving assets, so basically anything but JS/TS. Doesn't mean Vite shouldn't make it work also, just out of scope for this particular concern.
ember-auto-import needs a relatively small feature
@ef4 could you elaborate what that small feature would be? Are you saying we don't need the full webpack implementation as in https://github.com/webpack/webpack/issues/16693?
@ef4 could you elaborate what that small feature would be? Are you saying we don't need the full webpack implementation as in https://github.com/webpack/webpack/issues/16693?
Having proper upstream support like that would be ideal, but we're not blocked on it because we can transpile to similar syntax that webpack already supports. For webpack that would be import statements:
-let url = import.meta.resolve('./thing.png')
+import _the_thing_ from "./thing.png";
+let url = _the_thing_;
Same for vite (although I plan to take a look there to see if we can submit a PR with the proper upstream fix, because it seems likely to be a tiny change given the similarly with the syntax they already support):
-let url = import.meta.resolve('./thing.png')
+let url = new URL('./thing.png', import.meta.url);
Hello 👋, I've put together an experimental package babel-plugin-ember-import-meta to use import.meta from <template> including import.meta.resolve (and from JavaScript too).
It is a naive implementation, but it works with Vite based application (Webpack should work too) by transpiling to import statements as mentioned above (using new URL(..., import.meta.url) is not compatible with SSR).