Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 15 15:58
    timmywil unlabeled #5090
  • Aug 15 15:56

    timmywil on 3.x-stable

    Release: update AUTHORS.txt (compare)

  • Aug 15 15:44
    timmywil milestoned #5015
  • Aug 15 15:44
    timmywil demilestoned #5015
  • Aug 15 15:44
    timmywil demilestoned #4859
  • Aug 15 15:44
    timmywil milestoned #4950
  • Aug 15 15:44
    timmywil demilestoned #4950
  • Aug 15 15:44
    timmywil milestoned #4859
  • Aug 15 15:44
    timmywil milestoned #4856
  • Aug 15 15:44
    timmywil demilestoned #4856
  • Aug 14 21:31
    mgol synchronize #5085
  • Aug 14 21:24
    mgol synchronize #5085
  • Aug 14 20:59
    mgol commented #5085
  • Aug 14 20:58
    mgol edited #5085
  • Aug 14 20:58
    mgol labeled #5090
  • Aug 14 20:58
    mgol assigned #5090
  • Aug 14 20:58
    mgol labeled #5090
  • Aug 14 20:58
    mgol opened #5090
  • Aug 14 20:40
    mgol synchronize #5085
  • Aug 11 13:59
    mgol closed #5087
Michał Gołębiowski-Owczarek
@mgol
I also migrated jQuery Color & eslint-config-jquery (those ones I merged), we're down to 8 repos. When the Sizzle PR gets merged, we'll be able to go down to 7.
Michał Gołębiowski-Owczarek
@mgol
I also have a PR switching jquery-release: jquery/jquery-release#110
Timo Tijhof
@Krinkle
(Merged)
Michał Gołębiowski-Owczarek
@mgol
Down to 7 repos with Travis enabled; it will go down to 6 when the Sizzle PR gets merged. This may go quicker than I originally imagined.
Michał Gołębiowski-Owczarek
@mgol
@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.
Michał Gołębiowski-Owczarek
@mgol
@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.
Michał Gołębiowski-Owczarek
@mgol
@Krinkle Yet another case for limiting the dependency tree, especially it’s depth.
Timmy Willison
@timmywil
Sounds reasonable. It’ll be some work to get all the tasks working, but it’s what I already do in most projects.
Timo Tijhof
@Krinkle
@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.
Michał Gołębiowski-Owczarek
@mgol
@Krinkle is QUnit still using jquery-release for its releases?
Timo Tijhof
@Krinkle
It is not.
Michał Gołębiowski-Owczarek
@mgol
@timmywil npm has fixed the colors package, builds are working fine again
Timo Tijhof
@Krinkle
mgol: more specifically, I rewrote most of our (forked version of) jquery-release in plain dep-free JS scripts and changed a few steps to manual steps
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
Timmy Willison
@timmywil
Seems npm removed the corrupted versions of colors. We can leave the locked versions in jQuery core, but changes elsewhere should not be needed.
Richard Gibson
@gibson042
hi!
Timmy Willison
@timmywil
hi there
@mgol here?
Michał Gołębiowski-Owczarek
@mgol
hi
Timmy Willison
@timmywil
woops, wrong channel
Michał Gołębiowski-Owczarek
@mgol
@Krinkle The QUnit release script doesn't update the version in package-lock.json, making a bare npm install lead to a local dirty state. It'd be good to fix it; I did it for jquery-release a while ago.
Michał Gołębiowski-Owczarek
@mgol
Timo Tijhof
@Krinkle
@mgol microsoft aspnet link seems dead ("The resource you are looking for..")
Timmy Willison
@timmywil
probably not been uploaded to the microsoft cdn yet
Michał Gołębiowski-Owczarek
@mgol
yes; I'll ping them again
Saptak Sengupta
@SaptakS
seems like someone is spamming the jquery repo
Michał Gołębiowski-Owczarek
@mgol
Thx. The user is banned now.
Saptak Sengupta
@SaptakS
:+1:
Michał Gołębiowski-Owczarek
@mgol
I turned off security Dependabot alerts for Sizzle. Sizzle has no dependencies, only devDependencies and we cannot update the majority of them as newer versions of packages don't work with all those legacy browsers Sizzle tests against.
Because Sizzle was receiving so many alerts, ones for other repos never fit into the summary emails that GitHub sent.
Michał Gołębiowski-Owczarek
@mgol
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 ^
Michał Gołębiowski-Owczarek
@mgol
@timmywil BTW, I picked up the old @dmethvin's event refactor branch, I rebased it (it was 6 years old!) and I'm trying to make it work. Trying to finally get closer to the big 4.0 requirements. :)
Timmy Willison
@timmywil
nice! wow, 6 years
Michał Gołębiowski-Owczarek
@mgol
@timmywil @gibson042 @dmethvin I submitted a draft PR removing IE support, as we discussed during the meeting: jquery/jquery#5077.
Michał Gołębiowski-Owczarek
@mgol

@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.

Richard Gibson
@gibson042
what if we kept the IE code that can't be monkeypatched with hooks?
Michał Gołębiowski-Owczarek
@mgol
@gibson042 I'm not sure that's worth it. Size gains would not be too big, we'd still need to test it, etc. We can optionally provide the --no-ie flag that would cut off the code behind isIE; I already have it implemented on a branch.
Richard Gibson
@gibson042
ok
Michał Gołębiowski-Owczarek
@mgol
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.
Timmy Willison
@timmywil
I'd say keep the restriction until a problem gives us a reason to open it up. 99% of cases can be handled on regular nodes and plain objects.