Deprecate import Ember from 'ember'
#1003
Conversation
| if (macroCondition(isDevelopingApp())) { | ||
| // maybe this is side-effecting and installs | ||
| // some functions on `globalThis` that the inspector could call | ||
| importSync('@ember/inspector-support'); |
There was a problem hiding this comment.
I do not think this is necessary? What would this do? Inspector can use amd nodules. It's already using internal modules. There are surely better ways, but this might not be part of this rfc
There was a problem hiding this comment.
we will not always be compliing to AMD, so we need something a bit more robust / format-agnostic.
Like, in my side-projects (limber/tutorial on glimdown.com, and others), I want to be shipping actual ESM as my bundled format (some things need to land on The Platform first (multiple modules in one file):
https://github.com/tc39/proposal-module-declarations
There was a problem hiding this comment.
my proposal for inspector:
emberjs/ember.js#20580
There was a problem hiding this comment.
@patricklx Nice. Just curious, would emberjs/ember.js#20580 also help solve emberjs/ember.js#19705? (Ember.library.register is still mentioned as the preferred method to register a library in the docs.)
There was a problem hiding this comment.
We could move the singleton into ember/inspector-support and have apps register through there.
Or use alternatives like unplugin-info and have another api in @ember/inspector-support to register that info
| - `Ember.controllerFor` | ||
| - `Ember.generateController` | ||
| - `Ember.generateControllerFactory` | ||
| - `Ember.VERSION` |
There was a problem hiding this comment.
It's also required for inspector. A macro is not enough. It's in an amd module anyway.
There was a problem hiding this comment.
related: #1003 (comment)
| if (macroCondition(isDevelopingApp())) { | ||
| // maybe this is side-effecting and installs | ||
| // some functions on `globalThis` that the inspector could call | ||
| importSync('@ember/inspector-support'); | ||
| } |
There was a problem hiding this comment.
Using Ember Inspector on production build helps with debugging from time to time. What is the trade-off of supporting Ember Inspector in production build as well?
There was a problem hiding this comment.
My personal preference would be to have folks opt in to that by removing the condition and just importing inspector-support
|
|
||
| Utility | ||
| - 🫣 `Ember.lookup` | ||
| - 🌐 `Ember.libraries` - |
There was a problem hiding this comment.
Here is a replacement for not only libraries, but everything from the build environment:
https://github.com/NullVoxPopuli/embroider-with-webpack-build-plugins-demo
Uses: https://github.com/yjl9903/unplugin-info/tree/main
My code:
// in app/app.js
import * as info from '~build/package';
import * as meta from '~build/meta';
console.log(JSON.stringify({ info, meta }, null, 2));Output
{
"info": {
"author": "",
"dependencies": {
"unplugin-info": "^1.1.0"
},
"description": "Small description for embroider-with-webpack-build-plugins-demo goes here",
"devDependencies": {
"@babel/core": "^7.23.7",
"@babel/eslint-parser": "^7.23.3",
"@babel/plugin-proposal-decorators": "^7.23.7",
"@ember/optional-features": "^2.0.0",
"@ember/string": "^3.1.1",
"@ember/test-helpers": "^3.2.1",
"@embroider/compat": "^3.4.3",
"@embroider/core": "^3.4.3",
"@embroider/webpack": "^3.2.1",
"@glimmer/component": "^1.1.2",
"@glimmer/tracking": "^1.1.2",
"broccoli-asset-rev": "^3.0.0",
"concurrently": "^8.2.2",
"ember-auto-import": "^2.7.2",
"ember-cli": "~5.6.0",
"ember-cli-app-version": "^6.0.1",
"ember-cli-babel": "^8.2.0",
"ember-cli-clean-css": "^3.0.0",
"ember-cli-dependency-checker": "^3.3.2",
"ember-cli-htmlbars": "^6.3.0",
"ember-cli-inject-live-reload": "^2.1.0",
"ember-data": "~5.3.0",
"ember-fetch": "^8.1.2",
"ember-load-initializers": "^2.1.2",
"ember-modifier": "^4.1.0",
"ember-page-title": "^8.2.0",
"ember-qunit": "^8.0.2",
"ember-resolver": "^11.0.1",
"ember-source": "~5.6.0",
"ember-template-lint": "^5.13.0",
"ember-welcome-page": "^7.0.2",
"eslint": "^8.56.0",
"eslint-config-prettier": "^9.1.0",
"eslint-plugin-ember": "^11.12.0",
"eslint-plugin-n": "^16.6.2",
"eslint-plugin-prettier": "^5.1.3",
"eslint-plugin-qunit": "^8.0.1",
"loader.js": "^4.7.0",
"prettier": "^3.2.4",
"qunit": "^2.20.0",
"qunit-dom": "^2.0.0",
"stylelint": "^15.11.0",
"stylelint-config-standard": "^34.0.0",
"stylelint-prettier": "^4.1.0",
"tracked-built-ins": "^3.3.0",
"webpack": "^5.89.0"
},
"keywords": [],
"license": "MIT",
"name": "embroider-with-webpack-build-plugins-demo",
"version": "0.0.0"
},
"meta": {
"message": "Hello world!, from info.meta!"
}
}
NullVoxPopuli
added
S-Exploring
|
So we had a looooong conversation about this in the RFC Review (1) call, and @kategengler and I went back and forth a few times on how to progress this RFC. Essentially my understanding is that we need to ultimately decide if we are happy to drop every single thing in the As for making this discussion, the idea that we floated was to use the Ember Observer code search to check the usage of each item and if they are not actively being used then we're just ok to drop them. I don't exactly know what the cutoff for "actively being used" should be but if we agree in principle on the process then we can come up with a heuristic together. Does that accurately summarise the conversation @kategengler ? |
Co-authored-by: Katie Gengler <katie@kmg.io>
kategengler
force-pushed
the
deprecate-import-ember-from-ember
branch
from
6152119 to
b8b7975
Compare
RFC: emberjs/rfcs#1003 Guide: ember-learn/deprecation-app#1381 Advancement: emberjs/rfcs#1015
Propose deprecating
import Ember from 'ember'See: https://github.com/orgs/emberjs/projects/9/views/1?pane=issue&itemId=50454015
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