Turn on argument linting from no-unused-vars
Categories
(Developer Infrastructure :: Lint and Formatting, task)
Tracking
(firefox126 fixed)
| Tracking | Status | |
|---|---|---|
| firefox126 | --- | fixed |
People
(Reporter: Gijs, Assigned: mossop)
References
(Blocks 1 open bug, Regressed 1 open bug)
Details
Attachments
(66 files, 3 obsolete files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
no-unused-vars currently ignores unused function arguments.
Running this in browser/components/ (as a sample) finds about 220 issues.
A large portion of these seem to be cases where the method signature is defined elsewhere (e.g. handleEvent(event), observe(subject, topic, data)). It would be nice if we could ignore those, but it looks like eslint does not have a direct facility for this. You can specify patterns of variables to ignore but of course ignoring all arguments called data would probably not be great.
One option would be to switch code to use _ prefixes for unused arguments to make it explicit, and that could be a solution for these cases. This is an example given in the eslint docs with the argsIgnorePattern: /^_/ option, so is presumably a wider convention.
Thoughts on doing this?
Comment 1•2 years ago
|
||
I see around 800 issues, but I'm probably configuring it in a different place.
As you indicate there are two groups - the listener/observer/callback style of functions whose interfaces are defined elsewhere, and the functions which are being defined.
For the listener cases, I do find that it is often useful to have the arguments there, as they help remind me what the options are, especially when potentially extending a function. In those cases having _ would be a little annoying as it makes it harder to know what the item being skipped actually is. We could possibly use argsIgnorePattern: /^_.+/ as the option instead to enforce more than just _.
For the case where the code is defining the function, I think it is definitely useful - VS Code highlights this, but not everyone uses VS Code, nor will they necessarily spot it. There's definitely some places in our code where we have unused parameters that look wrong, and as a result we're unnecessarily passing extra items to those functions. These cases weren't always at the end of the arguments, some were at the start as well.
I think it could be quite a bit of work to enable, but I do think it would be worth it to help ensure code is tidied, especially when refactoring. To aid the roll-out we could potentially enable on non-test code first, and then think about test code later. From what I've seen, it would probably be worth enabling it on both eventually.
| Reporter | ||
Comment 2•2 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #1)
I see around 800 issues, but I'm probably configuring it in a different place.
As you indicate there are two groups - the listener/observer/callback style of functions whose interfaces are defined elsewhere, and the functions which are being defined.
For the listener cases, I do find that it is often useful to have the arguments there, as they help remind me what the options are, especially when potentially extending a function. In those cases having
_would be a little annoying as it makes it harder to know what the item being skipped actually is. We could possibly useargsIgnorePattern: /^_.+/as the option instead to enforce more than just_.
Yes, sorry, I did mean that we'd use _data or _event rather than just _.
| Assignee | ||
Comment 3•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #0)
A large portion of these seem to be cases where the method signature is defined elsewhere (e.g.
handleEvent(event),observe(subject, topic, data)). It would be nice if we could ignore those, but it looks likeeslintdoes not have a direct facility for this. You can specify patterns of variables to ignore but of course ignoring all arguments calleddatawould probably not be great.
But if the arguments aren't used in the function then not including them in the function signature is fine. Why would we want to leave them in?
| Reporter | ||
Comment 4•2 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #3)
(In reply to :Gijs (he/him) from comment #0)
A large portion of these seem to be cases where the method signature is defined elsewhere (e.g.
handleEvent(event),observe(subject, topic, data)). It would be nice if we could ignore those, but it looks likeeslintdoes not have a direct facility for this. You can specify patterns of variables to ignore but of course ignoring all arguments calleddatawould probably not be great.But if the arguments aren't used in the function then not including them in the function signature is fine. Why would we want to leave them in?
I think it helps make it clearer that it's an nsIObserver / event listener thingy, as opposed to a random function that has no args (esp. when the function has no name - nsIObserver has the idl function annotation so you can pass (subject, topic, data) => doStuff() to addObserver), and makes it obvious that input is available that could be used to help guide decisions inside the function, as well as reducing churn both for enabling the rule and when whether or not you use the arg changes (though that's moot if we go the prefix route as you'd still need to touch the line). But it's a fair point, we could also "just" strip everything that's unused, I guess - do you feel strongly we should?
| Assignee | ||
Comment 5•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #4)
(In reply to Dave Townsend [:mossop] from comment #3)
(In reply to :Gijs (he/him) from comment #0)
A large portion of these seem to be cases where the method signature is defined elsewhere (e.g.
handleEvent(event),observe(subject, topic, data)). It would be nice if we could ignore those, but it looks likeeslintdoes not have a direct facility for this. You can specify patterns of variables to ignore but of course ignoring all arguments calleddatawould probably not be great.But if the arguments aren't used in the function then not including them in the function signature is fine. Why would we want to leave them in?
I think it helps make it clearer that it's an nsIObserver / event listener thingy, as opposed to a random function that has no args (esp. when the function has no name -
nsIObserverhas the idlfunctionannotation so you can pass(subject, topic, data) => doStuff()toaddObserver), and makes it obvious that input is available that could be used to help guide decisions inside the function, as well as reducing churn both for enabling the rule and when whether or not you use the arg changes (though that's moot if we go the prefix route as you'd still need to touch the line). But it's a fair point, we could also "just" strip everything that's unused, I guess - do you feel strongly we should?
Honestly not too sure. If we think it is useful to mark observer functions using the arguments does that hold for other callback-like functions, should anything passed to Array.map be (item, index, arr) => {}? I think not but I can't say why that's different.
| Reporter | ||
Comment 6•2 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #5)
Honestly not too sure. If we think it is useful to mark observer functions using the arguments does that hold for other callback-like functions, should anything passed to
Array.mapbe(item, index, arr) => {}? I think not but I can't say why that's different.
I guess I'd think that for 99% of map functions I've ever written, a reference to the array or index are not useful. For observe(), I'd hazard a guess that in more than half of all cases outside of tests I'd want at least the topic, and often (maybe 10-30% of cases?) the subject and/or data as well.
But the flip side of my argument is that if someone were to write observe() {} or handleEvent() {}, the linter can't fault them for not listing the arguments that are technically still provided to the function. So wanting to list the args for education/"contract" purposes is only enforceable by convention / humans, which is bad. To change that we'd need typescript or something...
So even though, from a manual review PoV I'd never really comment on people having an unused event or subject/topic/data param for these functions, so the argument there would be to avoid touching code / making it harder to start using those args. But we can't really avoid touching that code while enabling the rule unless we add eslint-disable-next-line comments which is horrible so I don't want to do that. There's also no way to ignore arguments based on the name of the function rather than the argument.
So I think maybe we should just accept that these are gonna get clobbered by the linter if not used? There are probably already (many?) instances of observe() that don't list the last data arg (esp. when passing just an arrow function). Admittedly, there are only 3 cases of handleEvent without an arg in the entire tree... https://searchfox.org/mozilla-central/search?q=handleEvent%28%29+%7B&path=&case=true®exp=false but perhaps that speaks more to using the event? I haven't checked how many of the with-arg instances would be removed by the linter.
Sorry, lots of waffling to say that maybe I'm changing my mind and we should just go ahead and clobber all of this stuff. Perhaps it's shaped by just digging into some blame/annotate stuff and having to jump past a few eslint revisions. Comparatively, touching these lines isn't going to be the end of the world...
| Assignee | ||
Comment 7•2 years ago
•
|
||
(In reply to :Gijs (he/him) from comment #6)
(In reply to Dave Townsend [:mossop] from comment #5)
Honestly not too sure. If we think it is useful to mark observer functions using the arguments does that hold for other callback-like functions, should anything passed to
Array.mapbe(item, index, arr) => {}? I think not but I can't say why that's different.I guess I'd think that for 99% of map functions I've ever written, a reference to the array or index are not useful. For
observe(), I'd hazard a guess that in more than half of all cases outside of tests I'd want at least thetopic, and often (maybe 10-30% of cases?) thesubjectand/ordataas well.
Right. But I think those arguments are either useful or not and you know to add them when you're writing the function. I think it's rare that you realise later that you do actually need the data argument to an observe function. Maybe the main case being where you start observing a new topic for the same function at which point you know the function is an observer callback anyway.
But the flip side of my argument is that if someone were to write
observe() {}orhandleEvent() {}, the linter can't fault them for not listing the arguments that are technically still provided to the function. So wanting to list the args for education/"contract" purposes is only enforceable by convention / humans, which is bad. To change that we'd need typescript or something...
It's probably possible with a custom eslint rule, but it's work. And if we're only relying on function name I would expect most folks to recognise handleEvent and observe as standard functions and be able to find relatively easily what arguments they can take.
Sorry, lots of waffling to say that maybe I'm changing my mind and we should just go ahead and clobber all of this stuff. Perhaps it's shaped by just digging into some blame/annotate stuff and having to jump past a few eslint revisions. Comparatively, touching these lines isn't going to be the end of the world...
Ok now for the spanner in the works. I just attempt to turn this on, eslint gave me over 7,000 errors (that does include test files though), and the rule isn't automatically fixable so we'd have to correct everything by hand. I'm inclined to say that that isn't worth it.
| Assignee | ||
Comment 8•2 years ago
|
||
| Assignee | ||
Comment 9•2 years ago
|
||
Depends on D194400
| Assignee | ||
Comment 10•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 11•2 years ago
|
||
The WIP rule can now fix the entire tree and leaves the following errors:
jsdoc/check-param-names, descriptions of arguments that have been removed (114 instances).mozilla/no-unused-args, arguments that cannot be removed automatically because while they are never read from they are written to (20 instances).no-empty-pattern, some array destructurs are pointless but we can't remove them from the function arguments automatically (3 instances).
It fixes some 4311 occurrences.
So enough to say that this seems viable to do. So we should figure out if we want to do this for sure and what the plan should be. I'd suggest something like this:
- Announce on the mailing lists a plan to do this.
- Create patches for various parts of the tree to split up the review workload.
- Land.
After that we may be better off sticking with the eslint provided rule for checking this rather than the new version that supports autofixing. I found it to be a problem during development since I have my editor set to fix all lint issues automatically whenever I save, and if you save half-way through writing a new function it will strip the arguments for you.
| Reporter | ||
Comment 12•2 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #11)
The WIP rule can now fix the entire tree and leaves the following errors:
jsdoc/check-param-names, descriptions of arguments that have been removed (114 instances).
Follow-up bug and add eslint ignore comments for now? Then we can burn this down and potentially update callers that pass these now-unneeded arguments...
mozilla/no-unused-args, arguments that cannot be removed automatically because while they are never read from they are written to (20 instances).
I imagine this needs manual fixing?
no-empty-pattern, some array destructurs are pointless but we can't remove them from the function arguments automatically (3 instances).It fixes some 4311 occurrences.
So enough to say that this seems viable to do. So we should figure out if we want to do this for sure and what the plan should be. I'd suggest something like this:
- Announce on the mailing lists a plan to do this.
- Create patches for various parts of the tree to split up the review workload.
- Land.
After that we may be better off sticking with the eslint provided rule for checking this rather than the new version that supports autofixing. I found it to be a problem during development since I have my editor set to fix all lint issues automatically whenever I save, and if you save half-way through writing a new function it will strip the arguments for you.
Agreed on all counts. I think we should additionally split the test-only changes into their own patch(es) because they're lower-impact/risk, but other than that this all sounds good to me.
| Assignee | ||
Comment 13•1 year ago
|
||
(In reply to :Gijs (he/him) from comment #12)
(In reply to Dave Townsend [:mossop] from comment #11)
The WIP rule can now fix the entire tree and leaves the following errors:
jsdoc/check-param-names, descriptions of arguments that have been removed (114 instances).Follow-up bug and add eslint ignore comments for now? Then we can burn this down and potentially update callers that pass these now-unneeded arguments...
It might just be as easy to remove those doc comments, they aren't doing anything at that point.
mozilla/no-unused-args, arguments that cannot be removed automatically because while they are never read from they are written to (20 instances).I imagine this needs manual fixing?
Yes, some investigation too. The one case I looked at was in a test and made me wonder if the test was faulty.
Comment 14•1 year ago
|
||
I'm fine with the plan here - I think it'll help clean up unused params and simplify the callers.
(In reply to Dave Townsend [:mossop] from comment #11)
- Announce on the mailing lists a plan to do this.
- Create patches for various parts of the tree to split up the review workload.
- Land.
After that we may be better off sticking with the eslint provided rule for checking this rather than the new version that supports autofixing. I found it to be a problem during development since I have my editor set to fix all lint issues automatically whenever I save, and if you save half-way through writing a new function it will strip the arguments for you.
I think we should switch to the ESLint one eventually if we're able to (better for maintenance), whilst autofix for this is useful for tree-wide operations, I do wonder about it getting in the way.
One thing I did wonder about is would it work to make mozilla/no-unused-args use suggestions? According to the command line docs, you can get ESLint to auto fix only suggestions. What I don't know is how VS Code and others surface suggestions, I'd have assumed they wouldn't auto-fix, but do you still get the UI to accept the suggestion?
| Assignee | ||
Comment 15•1 year ago
|
||
(In reply to Mark Banner (:standard8) from comment #14)
One thing I did wonder about is would it work to make
mozilla/no-unused-argsuse suggestions? According to the command line docs, you can get ESLint to auto fix only suggestions. What I don't know is how VS Code and others surface suggestions, I'd have assumed they wouldn't auto-fix, but do you still get the UI to accept the suggestion?
That's a good call. In VS Code, at least how I have it configured which I assume is fairly normal, you do still see the error and get UI to accept the fix but it doesn't auto-fix on save anymore. Worth noting that you also get a similar suggestion to fix from VS Code's built-in TypeScript functionality.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 16•1 year ago
|
||
| Assignee | ||
Comment 17•1 year ago
|
||
Depends on D195630
| Assignee | ||
Comment 18•1 year ago
|
||
Depends on D195631
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 19•1 year ago
|
||
I see this is also considering autofixing class methods, which I don't think is a pure win. Even without typescript[1], it is considered good practice to define methods in base classes that don't do anything (and document their arguments with JSDoc) that can (or need) to be overridden in a subclass. Removing such arguments would result in invalid JSDoc comments.
[1] With typescript, this is actually a requirement, as the overriding function needs to have a signature that's compatible with the base one:
class A {
/** override to customize Foo */
do() {}
}
class B extends A {
/** @param {string} foo */
do(foo) {
console.log("B", foo);
}
}
This is a type-checking error (in JSDoc-hinted and) typescript-checked javascript. Btw, I have a patch up for progressively adding type-checks to /toolkit/components/extensions code in bug 1869678, and I'm fairly confident TypeScript is a better tool for trying to address the root problem here.
| Assignee | ||
Comment 20•1 year ago
|
||
(In reply to Tomislav Jovanovic :zombie from comment #19)
I see this is also considering autofixing class methods, which I don't think is a pure win. Even without typescript[1], it is considered good practice to define methods in base classes that don't do anything (and document their arguments with JSDoc) that can (or need) to be overridden in a subclass. Removing such arguments would result in invalid JSDoc comments.
The number of places we actually use base classes is fairly small right now and until we have something better this isn't a distinction we can reliably make so we either have to somehow turn off this rule for class methods, which isn't possible in the eslint provided rule and doesn't account for only the overrides case, or accept this. It was brought up in the mailing list discussion but it was agreed to go ahead as-is.
Can you elaborate on why JSDoc comments would be invalid?
I'm fairly confident TypeScript is a better tool for trying to address the root problem here.
Sure, but we're a long ways off being able to use TypeScript across the codebase.
Comment 21•1 year ago
•
|
||
The number of places we actually use base classes is fairly small right now
Some of these are WebIDL-based parent classes, but I don't think this is small:
https://searchfox.org/mozilla-central/search?q=class.%2Bextends&path=*.*js®exp=true
Can you elaborate on why JSDoc comments would be invalid?
class A {
/** @param {string} foo */
do(foo) {}
}
This would be the source of the base class before removal of foo. After removal, the JSDoc referencing a non-existing argument is invalid.
Sure, but we're a long ways off being able to use TypeScript across the codebase.
It looks more feasible to me than a few weeks ago, now that I have PoC in bug 1869678. Besides what's already there, I also have our [ChromeOnly] WebIDL definitions converted to a typescript lib-dom.d.ts locally (using a slightly patched TypeScript-DOM-lib-generator). I'll write up a case study/proposal after the holiday break if things work out as expected.
Comment 22•1 year ago
|
||
Removing unused arguments could be a bit annoying during development, when it's a WIP patch and you just haven't had the time to utilize the argument yet.
Comment 23•1 year ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #22)
Removing unused arguments could be a bit annoying during development, when it's a WIP patch and you just haven't had the time to utilize the argument yet.
The rule is not automatically fixed. You'll get a error like you do with other items, but it won't get removed.
| Assignee | ||
Comment 24•1 year ago
|
||
(In reply to Tomislav Jovanovic :zombie from comment #21)
The number of places we actually use base classes is fairly small right now
Some of these are WebIDL-based parent classes, but I don't think this is small:
https://searchfox.org/mozilla-central/search?q=class.%2Bextends&path=*.*js®exp=trueCan you elaborate on why JSDoc comments would be invalid?
class A { /** @param {string} foo */ do(foo) {} }This would be the source of the base class before removal of
foo. After removal, the JSDoc referencing a non-existing argument is invalid.
Right but that jsdoc comment won't be there of course.
Sure, but we're a long ways off being able to use TypeScript across the codebase.
It looks more feasible to me than a few weeks ago, now that I have PoC in bug 1869678. Besides what's already there, I also have our [ChromeOnly] WebIDL definitions converted to a typescript lib-dom.d.ts locally (using a slightly patched TypeScript-DOM-lib-generator). I'll write up a case study/proposal after the holiday break if things work out as expected.
With modules only maybe, I'll be interested to see that as it may fit in with my plans for the coming years. But looking at TypeScript it doesn't appear that it allows unused parameters in base classes either. See the example here where it throws an error on an unused argument in a base class despite another class making use of it.
| Assignee | ||
Comment 25•1 year ago
|
||
So essentially the issue with unused parameters in base classes is the same as that already discussed in the mailing list. That TypeScript will throw an error if we manage to get around to using it adds some weight but is also helpful. Right now we can't easily quantify the number of unused parameters in base classes that we shouldn't remove. My intuition tells me that it is lower than the number that we should remove. And if we manage to get TypeScript stood up then it will tell us exactly the places that we were wrong making fixing fairly straightforward. So I think we're better off going ahead with the plan. I realise that the final plan isn't actually documented in this bug as it altered slightly in the mailing list discussion so here is what we're doing:
- Via a combination of automated tooling and some manual fixups we're going to remove all parameters (and their jsdoc comments) from functions where the
no-unused-varsrule fails using the planned config. - Then we turn on the
no-unused-varsconfig which will error on unused parameters after any used parameters but allowing parameters that are prefixed with_.
As Mark mentioned the rule will not auto-fix as that is quite annoying in development (and also the eslint provided rule doesn't support autofixing anyway).
Comment 26•1 year ago
|
||
Comment 27•1 year ago
|
||
| bugherder | ||
| Assignee | ||
Comment 28•1 year ago
|
||
| Assignee | ||
Comment 29•1 year ago
|
||
| Assignee | ||
Comment 30•1 year ago
|
||
| Assignee | ||
Comment 31•1 year ago
|
||
| Assignee | ||
Comment 32•1 year ago
|
||
| Assignee | ||
Comment 33•1 year ago
|
||
| Assignee | ||
Comment 34•1 year ago
|
||
| Assignee | ||
Comment 35•1 year ago
|
||
| Assignee | ||
Comment 36•1 year ago
|
||
| Assignee | ||
Comment 37•1 year ago
|
||
| Assignee | ||
Comment 38•1 year ago
|
||
| Assignee | ||
Comment 39•1 year ago
|
||
| Assignee | ||
Comment 40•1 year ago
|
||
| Assignee | ||
Comment 41•1 year ago
|
||
| Assignee | ||
Comment 42•1 year ago
|
||
| Assignee | ||
Comment 43•1 year ago
|
||
| Assignee | ||
Comment 44•1 year ago
|
||
| Assignee | ||
Comment 45•1 year ago
|
||
| Assignee | ||
Comment 46•1 year ago
|
||
| Assignee | ||
Comment 47•1 year ago
|
||
| Assignee | ||
Comment 48•1 year ago
|
||
| Assignee | ||
Comment 49•1 year ago
|
||
| Assignee | ||
Comment 50•1 year ago
|
||
| Assignee | ||
Comment 51•1 year ago
|
||
| Assignee | ||
Comment 52•1 year ago
|
||
| Assignee | ||
Comment 53•1 year ago
|
||
| Assignee | ||
Comment 54•1 year ago
|
||
| Assignee | ||
Comment 55•1 year ago
|
||
| Assignee | ||
Comment 56•1 year ago
|
||
| Assignee | ||
Comment 57•1 year ago
|
||
| Assignee | ||
Comment 58•1 year ago
|
||
| Assignee | ||
Comment 59•1 year ago
|
||
| Assignee | ||
Comment 60•1 year ago
|
||
| Assignee | ||
Comment 61•1 year ago
|
||
| Assignee | ||
Comment 62•1 year ago
|
||
| Assignee | ||
Comment 63•1 year ago
|
||
| Assignee | ||
Comment 64•1 year ago
|
||
| Assignee | ||
Comment 65•1 year ago
|
||
| Assignee | ||
Comment 66•1 year ago
|
||
| Assignee | ||
Comment 67•1 year ago
|
||
| Assignee | ||
Comment 68•1 year ago
|
||
| Assignee | ||
Comment 69•1 year ago
|
||
| Assignee | ||
Comment 70•1 year ago
|
||
| Assignee | ||
Comment 71•1 year ago
|
||
| Assignee | ||
Comment 72•1 year ago
|
||
| Assignee | ||
Comment 73•1 year ago
|
||
| Assignee | ||
Comment 74•1 year ago
|
||
| Assignee | ||
Comment 75•1 year ago
|
||
| Assignee | ||
Comment 76•1 year ago
|
||
| Assignee | ||
Comment 77•1 year ago
|
||
| Assignee | ||
Comment 78•1 year ago
|
||
| Assignee | ||
Comment 79•1 year ago
|
||
| Assignee | ||
Comment 80•1 year ago
|
||
| Assignee | ||
Comment 81•1 year ago
|
||
| Assignee | ||
Comment 82•1 year ago
|
||
| Assignee | ||
Comment 83•1 year ago
|
||
| Assignee | ||
Comment 84•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 85•1 year ago
|
||
Comment 86•1 year ago
•
|
||
Backed out for causing newtab failures related to bundles.
-
Failure log
There are also this TV failures if you want to check them out before relanding this.
[task 2024-03-01T10:38:22.767Z] + cd /builds/worker/checkouts/gecko/browser/components/newtab
[task 2024-03-01T10:38:22.767Z] + rm -rf node_modules
[task 2024-03-01T10:38:22.768Z] + npm ci
[task 2024-03-01T10:38:23.362Z] npm WARN ERESOLVE overriding peer dependency
[task 2024-03-01T10:38:23.363Z] npm WARN While resolving: react-test-renderer@16.14.0
[task 2024-03-01T10:38:23.363Z] npm WARN Found: react@16.13.1
[task 2024-03-01T10:38:23.363Z] npm WARN node_modules/react
[task 2024-03-01T10:38:23.363Z] npm WARN react@"16.13.1" from the root project
[task 2024-03-01T10:38:23.363Z] npm WARN 7 more (@fluent/react, airbnb-prop-types, ...)
[task 2024-03-01T10:38:23.363Z] npm WARN
[task 2024-03-01T10:38:23.363Z] npm WARN Could not resolve dependency:
[task 2024-03-01T10:38:23.363Z] npm WARN peer react@"^16.14.0" from react-test-renderer@16.14.0
[task 2024-03-01T10:38:23.363Z] npm WARN node_modules/enzyme-adapter-react-16/node_modules/react-test-renderer
[task 2024-03-01T10:38:23.363Z] npm WARN react-test-renderer@"^16.0.0-0" from enzyme-adapter-react-16@1.15.6
[task 2024-03-01T10:38:23.363Z] npm WARN node_modules/enzyme-adapter-react-16
[task 2024-03-01T10:38:23.363Z] npm WARN
[task 2024-03-01T10:38:23.363Z] npm WARN Conflicting peer dependency: react@16.14.0
[task 2024-03-01T10:38:23.363Z] npm WARN node_modules/react
[task 2024-03-01T10:38:23.363Z] npm WARN peer react@"^16.14.0" from react-test-renderer@16.14.0
[task 2024-03-01T10:38:23.363Z] npm WARN node_modules/enzyme-adapter-react-16/node_modules/react-test-renderer
[task 2024-03-01T10:38:23.364Z] npm WARN react-test-renderer@"^16.0.0-0" from enzyme-adapter-react-16@1.15.6
[task 2024-03-01T10:38:23.364Z] npm WARN node_modules/enzyme-adapter-react-16
[task 2024-03-01T10:38:25.895Z] npm WARN deprecated sinon@12.0.1: 16.1.1
[task 2024-03-01T10:38:26.203Z]
[task 2024-03-01T10:38:26.203Z] added 590 packages, and audited 591 packages in 3s
[task 2024-03-01T10:38:26.203Z]
[task 2024-03-01T10:38:26.203Z] 130 packages are looking for funding
[task 2024-03-01T10:38:26.203Z] run `npm fund` for details
[task 2024-03-01T10:38:26.205Z]
[task 2024-03-01T10:38:26.205Z] found 0 vulnerabilities
[task 2024-03-01T10:38:26.218Z] + node bin/try-runner.js
[task 2024-03-01T10:38:26.335Z] TEST-START | bundles
[task 2024-03-01T10:38:35.840Z] TEST-UNEXPECTED-FAIL | bundles | Activity Stream bundle out of date
[task 2024-03-01T10:38:35.840Z] TEST-UNEXPECTED-FAIL | bundles | about:asrouter bundle out of date
[task 2024-03-01T10:38:35.841Z] TEST-START | karma /builds/worker/checkouts/gecko/browser/components/newtab
[task 2024-03-01T10:39:00.847Z] webpack was not included as a framework in karma configuration, setting this automatically...
[task 2024-03-01T10:39:00.853Z] -----karma stdout below this line---
[task 2024-03-01T10:39:00.855Z]
[task 2024-03-01T10:39:00.855Z] > activity-streams@1.14.3 testmc:unit
[task 2024-03-01T10:39:00.855Z] > karma start karma.mc.config.js
[task 2024-03-01T10:39:00.855Z]
[task 2024-03-01T10:39:00.855Z]
[task 2024-03-01T10:39:00.855Z] START:
[task 2024-03-01T10:39:00.855Z] Webpack bundling...
Comment 87•1 year ago
|
||
Comment 88•1 year ago
|
||
Backed out for causing node failures.
- backout: https://hg.mozilla.org/integration/autoland/rev/d93171a594b89c79014b1451b15a1f09534af299
- push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&selectedTaskRun=V6ku6IJMQLab1XbE2j-esw.0&revision=adba0b352699a1fc00c51a5a9beb3cf3d5b41949
- failure log: https://treeherder.mozilla.org/logviewer?job_id=449128170&repo=autoland&lineNumber=375
[task 2024-03-01T16:06:59.515Z] npm WARN ERESOLVE overriding peer dependency
[task 2024-03-01T16:06:59.516Z] npm WARN While resolving: react-test-renderer@16.14.0
[task 2024-03-01T16:06:59.516Z] npm WARN Found: react@16.13.1
[task 2024-03-01T16:06:59.516Z] npm WARN node_modules/react
[task 2024-03-01T16:06:59.516Z] npm WARN react@"16.13.1" from the root project
[task 2024-03-01T16:06:59.516Z] npm WARN 7 more (@fluent/react, airbnb-prop-types, ...)
[task 2024-03-01T16:06:59.517Z] npm WARN
[task 2024-03-01T16:06:59.517Z] npm WARN Could not resolve dependency:
[task 2024-03-01T16:06:59.517Z] npm WARN peer react@"^16.14.0" from react-test-renderer@16.14.0
[task 2024-03-01T16:06:59.517Z] npm WARN node_modules/enzyme-adapter-react-16/node_modules/react-test-renderer
[task 2024-03-01T16:06:59.517Z] npm WARN react-test-renderer@"^16.0.0-0" from enzyme-adapter-react-16@1.15.6
[task 2024-03-01T16:06:59.517Z] npm WARN node_modules/enzyme-adapter-react-16
[task 2024-03-01T16:06:59.517Z] npm WARN
[task 2024-03-01T16:06:59.517Z] npm WARN Conflicting peer dependency: react@16.14.0
[task 2024-03-01T16:06:59.517Z] npm WARN node_modules/react
[task 2024-03-01T16:06:59.517Z] npm WARN peer react@"^16.14.0" from react-test-renderer@16.14.0
[task 2024-03-01T16:06:59.517Z] npm WARN node_modules/enzyme-adapter-react-16/node_modules/react-test-renderer
[task 2024-03-01T16:06:59.517Z] npm WARN react-test-renderer@"^16.0.0-0" from enzyme-adapter-react-16@1.15.6
[task 2024-03-01T16:06:59.517Z] npm WARN node_modules/enzyme-adapter-react-16
[task 2024-03-01T16:07:02.771Z] npm WARN deprecated sinon@12.0.1: 16.1.1
[task 2024-03-01T16:07:03.200Z]
[task 2024-03-01T16:07:03.200Z] added 590 packages, and audited 591 packages in 4s
[task 2024-03-01T16:07:03.200Z]
[task 2024-03-01T16:07:03.200Z] 130 packages are looking for funding
[task 2024-03-01T16:07:03.200Z] run `npm fund` for details
[task 2024-03-01T16:07:03.202Z]
[task 2024-03-01T16:07:03.202Z] found 0 vulnerabilities
[task 2024-03-01T16:07:03.217Z] + node bin/try-runner.js
[task 2024-03-01T16:07:03.361Z] TEST-START | bundles
[task 2024-03-01T16:07:14.308Z] TEST-UNEXPECTED-FAIL | bundles | about:asrouter bundle out of date
Comment 89•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 90•1 year ago
|
||
Depends on D202958
Comment 91•1 year ago
|
||
Updated•1 year ago
|
Comment 92•1 year ago
|
||
Comment 93•1 year ago
|
||
| bugherder | ||
Comment 94•1 year ago
|
||
Comment 95•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/32438d22907c
https://hg.mozilla.org/mozilla-central/rev/a04b7236ed7a
https://hg.mozilla.org/mozilla-central/rev/eace859b61a8
https://hg.mozilla.org/mozilla-central/rev/89aaa62ca38e
https://hg.mozilla.org/mozilla-central/rev/f9ffc7a620f6
https://hg.mozilla.org/mozilla-central/rev/cff0ad593c6f
https://hg.mozilla.org/mozilla-central/rev/a2c7e0410903
https://hg.mozilla.org/mozilla-central/rev/1282ba5b87fa
https://hg.mozilla.org/mozilla-central/rev/346d01e58886
https://hg.mozilla.org/mozilla-central/rev/14d89bbe01dd
https://hg.mozilla.org/mozilla-central/rev/43590688afb0
https://hg.mozilla.org/mozilla-central/rev/ad3eae3f8eb5
https://hg.mozilla.org/mozilla-central/rev/a996fce8b781
https://hg.mozilla.org/mozilla-central/rev/89199aa6a41f
https://hg.mozilla.org/mozilla-central/rev/d5b31dfc3ce7
https://hg.mozilla.org/mozilla-central/rev/46e3ab5ca2e1
https://hg.mozilla.org/mozilla-central/rev/c86c685ccd56
https://hg.mozilla.org/mozilla-central/rev/ac7b674e512d
https://hg.mozilla.org/mozilla-central/rev/17be15b00ed6
https://hg.mozilla.org/mozilla-central/rev/73dfdbaaabe3
https://hg.mozilla.org/mozilla-central/rev/3c9944598f6c
https://hg.mozilla.org/mozilla-central/rev/2880fbdc5ca5
https://hg.mozilla.org/mozilla-central/rev/6b31316615e4
https://hg.mozilla.org/mozilla-central/rev/bb643e585fb3
https://hg.mozilla.org/mozilla-central/rev/832fed5aae75
https://hg.mozilla.org/mozilla-central/rev/c204f4699549
Comment 96•1 year ago
|
||
Comment 97•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/82e9d69d4c83
https://hg.mozilla.org/mozilla-central/rev/8e7bfcf84651
https://hg.mozilla.org/mozilla-central/rev/9fb6bc7e6180
https://hg.mozilla.org/mozilla-central/rev/069af7518db5
https://hg.mozilla.org/mozilla-central/rev/d1e884636a6f
https://hg.mozilla.org/mozilla-central/rev/a635cd6e99ff
Comment 98•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 99•1 year ago
|
||
| bugherder | ||
Comment 100•1 year ago
|
||
Comment 101•1 year ago
|
||
| bugherder | ||
Comment 102•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 103•1 year ago
|
||
| bugherder | ||
Comment 104•1 year ago
|
||
Comment 105•1 year ago
|
||
| bugherder | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 106•1 year ago
|
||
Comment 107•1 year ago
|
||
Comment 108•1 year ago
|
||
| bugherder | ||
Comment 109•1 year ago
|
||
| bugherder | ||
| Assignee | ||
Comment 110•1 year ago
|
||
| Assignee | ||
Comment 111•1 year ago
|
||
| Assignee | ||
Comment 112•1 year ago
|
||
| Assignee | ||
Comment 113•1 year ago
|
||
Comment 114•1 year ago
|
||
Comment 115•1 year ago
|
||
| Assignee | ||
Comment 116•1 year ago
|
||
Updated•1 year ago
|
Comment 117•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
Comment 118•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a07b3efb7f4b
https://hg.mozilla.org/mozilla-central/rev/c42f1ab7f7c5
https://hg.mozilla.org/mozilla-central/rev/029ec74cbc4a
https://hg.mozilla.org/mozilla-central/rev/42e0c42e5e1c
https://hg.mozilla.org/mozilla-central/rev/79b454f01f93
https://hg.mozilla.org/mozilla-central/rev/03dd6d250e9b
Description
•