This bug is a continuation of bug 1413156, which has gotten a bit long since all PRs were put into the same bug. Treeherder currently uses the lodash library (https://lodash.com) throughout the codebase for historical reasons, however many of the usages can now be replaced by modern plain ES6 Javascript, which avoids using yet another dependency that increases the JS bundle size. For anyone wanting to work on this: 1) No need to ask here if it's ok to start working on it - just dig in! :-) 2) Take a look at the list of lodash functions that we currently use: https://public.etherpad-mozilla.org/p/treeherder-lodash-to-es6 (I'll try to update this list periodically) ...and compare to this guide that says which lodash functions are good candidates for replacing with plain javascript: https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore 3) If you find a good candidate: - check there is not already a bug for it in the dependency tree of this bug - presuming there isn't, **file a new bug** in the "Treeherder: Frontend" component and mark it blocking this bug. A good bug title might be something like "Convert lodash .nameOfFunction() to native ES6". 4) Fork/clone the Treeherder source: https://github.com/mozilla/treeherder 5) Get a local UI instance working by following the steps here: https://treeherder.readthedocs.io/ui/installation.html#running-the-standalone-development-server 6) Make your changes & check the local instance still works 7) Run the tests/linter locally: https://treeherder.readthedocs.io/ui/installation.html#validating-javascript https://treeherder.readthedocs.io/ui/installation.html#running-the-unit-tests 8) Commit your changes, making sure to: - Use a branch other then master - Start the commit message with "Bug NNNNNNN - " where NNNNNNN is the number of the new bug you filed (**not this meta bug**) 9) Push your changes to GitHub and open a pull request, making sure to use the same "Bug NNNNNNN - " prefix for the PR title, so the bot knows which bug to link the attachment to. 10) Press "details" on the attachment that the robot created in Bugzilla and select someone from the "suggested reviewers" list to review. (Or if Bugzilla doesn't let you do this due to permissions, just comment in the bug asking for review). Good luck & thank you in advance! :-)

can I work on this? currently setting up a local environment for treeherder.

See (1) above.

How to debug files inside ui/js/controllers/perf or ui/js/services/perf folder? i can not see them in web inspector.

Make sure to use the unminified site (ie `yarn start`), switch to Perfherder (menu top left -> "Perfherder"), open the debugger and then under the "webpack" entry there are the original file names.

While I understand using es6 map/filter/etc when they are a 1:1 replacement for a lodash function, it feels like many of the cases where we're replacing lodash come with a substantial loss in terms of comprehensibility. The lodash functions have the advantage of having documentation describing what they're doing (https://lodash.com/docs/), which an adhoc reduce statement does not. Now that the obvious cases (_.map -> map, _.find -> find, etc.) seem to be taken care of, could we maybe move towards using the approach in bug 1468305 of just importing the appropriate lodash functions directly? That should give treeherder/perfherder the code size benefit without the loss of comprehensibility or the risk of breakage.

(In reply to William Lachance (:wlach) (use needinfo!) from comment #6) > The lodash functions have the advantage of having documentation describing > what they're doing (https://lodash.com/docs/), which an adhoc reduce > statement does not. The lodash docs are actually pretty lacking IMO. The reason for the bugs so far have mostly been due to features/implementation quirks of lodash that were undocumented, meaning we didn't know to watch out for them when converting. However I agree some of the cases result in worse readability, and so should be converted to the more precise lodash import style rather than to native JS for now. Hopefully future major versions of lodash will also start distributing both ES6 and ES5 assets, so we don't have the bloat from it having to support older browsers (there's currently lodash-es but it has its own set of issues aiui).

Depends on: 1476541

(Removing good first bug annotations since not too many lodash usages left, and so the contributors who've worked/are working on the dep bugs will probably be enough to carry this across the line)

For anyone working on the remaining usages - if the equivalent native modern JS is too verbose, let's stick with lodash for that particular function, but adjust the import to import directly, so it works better with tree shaking. For example: `import chunk from 'lodash/chunk'` (we'll also be switching to lodash-es soon)

Commit pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/f8b2f479599ac26c2d4fcfc25612a50f48e48ea5 Bug 1466494 - Convert global lodash imports to specific imports (#4149)

I'm actually curious if anyone has found a way to do a vanilla _.countBy without it being too verbose. I suppose PM me if you have a solution as not to have unnecessary comment on the bug report.

Closing since the majority of the usages have been converted over, and the rest we'll leave for now since their size impact will be less once we switch to lodash-es (in a bug I'm about to file shortly). (In reply to forrestblade.code from comment #13) > I'm actually curious if anyone has found a way to do a vanilla _.countBy > without it being too verbose. I suppose PM me if you have a solution as not > to have unnecessary comment on the bug report. I don't think we have yet unforunately.