@timmywil separately from the
colors issue, could you do a conceptual review of Migrate PR for disabling patches: jquery/jquery-migrate#450 as well? Dave seems happy about the direction but your input would be valuable as well before I write tests, etc.
@timmywil I’ve been wondering for some time whether we should get rid of grunt. The project is in maintenance mode and mostly just received obvious security fixes. We’d have better control of our dependencies if we cut out the middleman. It’s not like our build process is overly complex.
We would need replacements for a few tasks like compare_size & npmcopy but it sounds doable for me.
@mgol yep, removing grunt has been a huge step in making local dev tooling more secure in some of my projects, as it tends to make up a significant part of the dep tree in practice, many subportions of which are dated indeed. I don't worry about vulns in the old code as much as account breach publishing updates in a way that is automatically applied after a lock file update.
The steps that need to execute non trivial code are separated such that they can run in any kind of docker shell you might have, isolated and without git/shell ability exposed to it
And the final steps to publish are then run manually from your machine where you have those credentials available
@mgol here?
Because Sizzle was receiving so many alerts, ones for other repos never fit into the summary emails that GitHub sent.
I added a few of you to the requested reviewers of jquery/jquery#5068 as I'd like some additional eyes before recommending ditching one performance improvement for Android 4.0.
@timmywil @dmethvin @gibson042 ^
@timmywil @gibson042 @dmethvin I submitted a draft PR removing IE support, as we discussed during the meeting: jquery/jquery#5077.
@gibson042 re your:
anyone who still needs IE can load polyfills before jQuery, and we can even provide one if that's sufficiently cumbersome
from the meeting - I'm not sure if that's feasible. As can be seen in my PR, IE has lots of quirks that wouldn't be patched by any polyfill - like the need for double serialization of anchor.href, try-catch in multiple places, async focus+blur, crashes when strict equality comparison is used to compare documents...
What's done via attrHooks and the like could optionally be provided separately but all those other fixes would be hard to extract.
I've just checked: the first time
nodeType restrictions have been applied on nodes for the purpose of attaching data was in 1.9.1, for https://bugs.jquery.com/ticket/8335 - to handle comment nodes that are not cleaned up by .remove() & similar APIs.
but we now attach data directly on elements so perhaps this restriction is obsolete now?
we could allow 11 in 3.x to be on the safe side and completely drop this logic in 4.0. Thoughts?
Hmm, although, the logic in
jQuery.cleanData is still non-trivial, even now. So there are possibilities of potential issues here.