On 29/08/2019 20:01, Ben Rosser wrote:
Hm, does it make sense then to have a compatibility package for lodash3?
I think we may have to multiversion it yes. Been thinking that for a while.
I'll try and have a look at doing a lodash4 version of the spec over the weekend...
dnf repoquery --whatrequires nodejs-lodash says:
You need to look at all the nodejs-lodash-xxx modules as well which are built from the same source, although they don't make as much difference as I expected. That and BRs which I haven't looked at.
My guess is also that at least *some* of these packages have a newer release which support lodash 4 but no one has updated the package, whether because the package is effectively unmaintained or the maintainer is overworked or worried about breaking dependencies. :(
Oh probably quite a lot do, it's been a bit chicken and egg having to try and do everything at once, or even audit what is actually doable - ie what dependants have a new version with support.
For instance, looking at the last package on this list... the current version of zip-stream is 2.1.2 and does not actually require lodash at all anymore.
https://github.com/archiverjs/node-zip-stream/blob/master/package.json
Somebody should update it then ;-)
Tom
On Fri, Aug 30, 2019 at 3:59 AM Tom Hughes tom@compton.nu wrote:
On 29/08/2019 20:01, Ben Rosser wrote:
Hm, does it make sense then to have a compatibility package for lodash3?
I think we may have to multiversion it yes. Been thinking that for a while.
I'll try and have a look at doing a lodash4 version of the spec over the weekend...
Great, thanks for looking into it!
My guess is also that at least *some* of these packages have a newer release which support lodash 4 but no one has updated the package, whether because the package is effectively unmaintained or the maintainer is overworked or worried about breaking dependencies. :(
Oh probably quite a lot do, it's been a bit chicken and egg having to try and do everything at once, or even audit what is actually doable - ie what dependants have a new version with support.
Yeah, that's very fair. I've been thinking for a while now-- and this is probably a separate discussion than just grunt/lodash-- that it would be very useful to do a thorough audit of all the nodejs-* packages in Fedora and figure out which ones are outdated, which ones are uninstallable due to some other package having an unsatisfied dependency, which dependent packages are outdated, etc.
I've only looked into grunt now because it breaking broke one of my packages. But it would be really nice to be more proactive here. As it is, I fear a reasonable number of the nodejs-* packages in Fedora right now may not actually be very useful...
Ben Rosser
On 30/08/2019 14:44, Ben Rosser wrote:
On Fri, Aug 30, 2019 at 3:59 AM Tom Hughes tom@compton.nu wrote:
On 29/08/2019 20:01, Ben Rosser wrote:
Hm, does it make sense then to have a compatibility package for lodash3?
I think we may have to multiversion it yes. Been thinking that for a while.
I'll try and have a look at doing a lodash4 version of the spec over the weekend...
Great, thanks for looking into it!
So I now have a working spec for v4 and having now refreshed my memory of how it all works I think the issues may not be as bad as I remembered.
Anything which uses nodejs-lodash and loads the whole thing, or a whole group, so things like:
require("lodash") require("lodash/array")
should be fine, obviously modulo any changes to how the lodash methods work or removal of old methods.
So should anything which uses one of the split out single method modules like nodejs-lodash-pad.
Both nodejs-lodash-compat and nodejs-lodash-node go away but there is appears to be nothing actually using them.
The remaining issue is things using nodejs-lodash and loading an individual method with something like:
require("lodash/array/chunk")
which would now need to change to:
require("lodash/chunk")
Given all this I'm kind of tempted to just go for it and do the update and then fixup the dependants, which are far less than my memory suggested, maybe because so many things have been retired now.
Tom
On Sun, Sep 1, 2019 at 6:16 AM Tom Hughes tom@compton.nu wrote:
On 30/08/2019 14:44, Ben Rosser wrote:
On Fri, Aug 30, 2019 at 3:59 AM Tom Hughes tom@compton.nu wrote:
On 29/08/2019 20:01, Ben Rosser wrote:
Hm, does it make sense then to have a compatibility package for lodash3?
I think we may have to multiversion it yes. Been thinking that for a while.
I'll try and have a look at doing a lodash4 version of the spec over the weekend...
Great, thanks for looking into it!
So I now have a working spec for v4 and having now refreshed my memory of how it all works I think the issues may not be as bad as I remembered.
Anything which uses nodejs-lodash and loads the whole thing, or a whole group, so things like:
require("lodash") require("lodash/array")
should be fine, obviously modulo any changes to how the lodash methods work or removal of old methods.
So should anything which uses one of the split out single method modules like nodejs-lodash-pad.
Both nodejs-lodash-compat and nodejs-lodash-node go away but there is appears to be nothing actually using them.
The remaining issue is things using nodejs-lodash and loading an individual method with something like:
require("lodash/array/chunk")
which would now need to change to:
require("lodash/chunk")
Given all this I'm kind of tempted to just go for it and do the update and then fixup the dependants, which are far less than my memory suggested, maybe because so many things have been retired now.
Tom
Hi Tom,
I'm certainly in favor of going ahead with this, and no one seems to have objected (at least not on this list). Let me know if I can do something to help.
Cheers, Ben
On 11/09/2019 16:08, Ben Rosser wrote:
I'm certainly in favor of going ahead with this, and no one seems to have objected (at least not on this list). Let me know if I can do something to help.
I've updated lodash in rawhide, and hopefully fixed the worst of the resulting fallout.
I also updated grunt-legacy-log-utils and grunt-legacy-log though I have no idea if they still work as I had to disable the tests because there are circular dependencies on the rest of grunt but hopefully once you update that I can turn them back on.
Tom
On Sun, Sep 15, 2019 at 8:42 PM Tom Hughes tom@compton.nu wrote:
On 11/09/2019 16:08, Ben Rosser wrote:
I'm certainly in favor of going ahead with this, and no one seems to have objected (at least not on this list). Let me know if I can do something to help.
I've updated lodash in rawhide, and hopefully fixed the worst of the resulting fallout.
I also updated grunt-legacy-log-utils and grunt-legacy-log though I have no idea if they still work as I had to disable the tests because there are circular dependencies on the rest of grunt but hopefully once you update that I can turn them back on.
Tom
-- Tom Hughes (tom@compton.nu) http://compton.nu/
Hi Tom,
Thanks for taking care of this!
I've opened a pull request to update the main nodejs-grunt package, as I don't own it (though the SIG apparently has permissions): https://src.fedoraproject.org/rpms/nodejs-grunt/pull-request/1
I verified the built package installs in mock under Rawhide. Though I've turned off the tests for the same reason (I think some of the other grunt packages, including grunt-contrib-watch [1] need to be updated too).
Cheers, Ben
nodejs@lists.fedoraproject.org
-
Ben Rosser -
Tom Hughes