-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[CLEANUP beta] Remove jQuery from build #19677
Conversation
@simonihmig this diff should fix the eslint issues and after rebasing the tests should pass as well diff --git a/ember-cli-build.js b/ember-cli-build.js
index cdf3daf58..5c92e7a61 100644
--- a/ember-cli-build.js
+++ b/ember-cli-build.js
@@ -14,7 +14,6 @@ Error.stackTraceLimit = Infinity;
const {
routerES,
- jquery,
loader,
qunit,
handlebarsES,
diff --git a/lib/index.js b/lib/index.js
index 19bf17a76..778268f56 100644
--- a/lib/index.js
+++ b/lib/index.js
@@ -3,7 +3,6 @@
const MergeTrees = require('broccoli-merge-trees');
const Funnel = require('broccoli-funnel');
const path = require('path');
-const resolve = require('resolve');
const concatBundle = require('./concat-bundle');
const buildDebugMacroPlugin = require('./build-debug-macro-plugin');
const buildStripClassCallcheckPlugin = require('./build-strip-class-callcheck-plugin'); |
1689cfb
to
46c0b2e
Compare
Yeah, thanks @nlfurniss! Ready for Review! @mixonic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Close! I kicked off a rebuild to get around browserstack issues. This is very exciting.
this.ui.writeWarnLine( | ||
'Setting the `jquery-integration` optional feature flag to `true`, or not providing a setting at all, has been deprecated. You must add the `@ember/optional-features` addon and set this feature to `false`. This warning will become an error in Ember 4.0.0.\n\nFor more information, see the deprecation guide: https://deprecations.emberjs.com/v3.x/#toc_optional-feature-jquery-integration' | ||
const SilentError = require('silent-error'); | ||
throw new SilentError( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the right thing to do? Or should we assert if anyone sets this feature enabled/disabled at all? As in, they should just remove it from their configuration.
The approach of require false
is certainly more gentle, but a new 4.0 user would probably look curiously at a requirement to set a feature to disabled which... could not possibly be enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, right, I actually meant to only throw when this is explicitly set to true. I (wrongly) assumed this is already false by default, but it is not. So I will need to revisit this, to make it match RFC705 Phase 2. So I would basically use isFeatureExplicitlySet
to check if is explicitly set to true, or do noting (optional feature has no effect) otherwise, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have addressed this now!
Seems FF and Browserstack tests are still failing, so something real? 🤔 Wouldn't know why though. |
46c0b2e
to
8a8b8ce
Compare
@@ -134,7 +126,7 @@ | |||
testsTotal = testsPassed = testsFailed = 0; | |||
|
|||
if (QUnit.urlParams.hideskipped) { | |||
$('#qunit-tests').addClass('hideskipped'); | |||
document.getElementById('qunit-tests').classList.add('hideskipped'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the reason for failing FF and Browserstack tests! They used hideskipped
in testem.ci-browsers.js
, which was still jQuery based here. Still don't understand why this gave us these obscure error messages...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!!!
This took too long to make it green, sorry about that. But it finally passes all tests! 🎉 I was able to reproduce the failing Firefox CI job failure and fix it, see the inline comments... so @mixonic this is ready now for final review! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @simonihmig! Only one minor comment left...
) { | ||
const SilentError = require('silent-error'); | ||
throw new SilentError( | ||
'Setting the `jquery-integration` optional feature flag to `true` was deprecated in Ember 3.x and removed in Ember 4.0.0. You must add the `@ember/optional-features` addon and set this feature to `false`.\n\nFor more information, see the deprecation guide: https://deprecations.emberjs.com/v3.x/#toc_optional-feature-jquery-integration' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this prose needs work now that the logic has changed. We don't want folks installing the optional features addon at all, we want them to remove the configuration from their optional-features.json
file...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, ok, I can change that. But I vaguely remember in some past conversations (around jQuery RFCs) that the JSON file was considered an implementation details that users should not directly interact with, rather the "public API" is to use the commands provided by the addon, right? However there is no "remove" command AFAIK. So should I indeed point users to edit the optional-features.json
file directly?
Personally, I am not too much worried about this, just want to make sure...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rwjblue ping 👆 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not inclined to block on getting this dialed in exactly. It seems like we do lack some kind of followup logic for optional features- an ability to see what current settings match the ideal state and GC. Regardless setting to false
is harmless.
I'm happy to see another PR with further work here (or maybe even across Ember and the optional features repo), but I'm going to land this patch so we can get it into betas ASAP.
@@ -134,7 +126,7 @@ | |||
testsTotal = testsPassed = testsFailed = 0; | |||
|
|||
if (QUnit.urlParams.hideskipped) { | |||
$('#qunit-tests').addClass('hideskipped'); | |||
document.getElementById('qunit-tests').classList.add('hideskipped'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!!!
Removes jQuery from dependencies, the build process and test runs.
…licitly enabled.
49ae891
to
52413c2
Compare
I've force pushed a rebase. |
Thank you @simonihmig! This is incredible work. |
Thanks @mixonic, happy to have helped putting an end to this looong story (jQuery removal) 😀 There is still a bit of jQuery cruft in comments and API docs. Nothing which is super important to fix for the major release I think. I can do that when I find the time, but if someone else reads this and wants to contribute: just search for jQuery across the repo... |
Removes jQuery from dependencies, the build process and test runs.
Should be passing once the other open jQuery related PRs have landed (#19666, #19675, #19676)