Optimize traverseDependencyTree

[crubier]

What's the problem this PR addresses?

Resolves a runtime performance problem for large monorepos mentioned in

#1817 (comment)

...

How did you fix it?

removing seen.delete() as proposed by @larixer

...

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I have verified that all automated PR checks pass.

[crubier]

@larixer sadly this MR seem to actually cause some tests to fail https://github.com/yarnpkg/berry/pull/1826/checks?check_run_id=1092845086

[arcanis]

I'll check that later, but the failure is unrelated. TS probably just released something that has a merge conflict with our patch.

[crubier]

@arcanis indeed, I also thought that using latest in test was not ideal. Why not pin the version ?

[arcanis]

Because that's the point of this test, to detect problems with newly released versions 😛 However perhaps we should trigger them on schedule as well, since in this case we didn't notice it until after your PR (it's only a dev release though - not a huge problem for now).

[arcanis]

Also note that I think I'll hold this PR a little bit, I'd like to expose a getAllLocators function in the PnP API. This would allow to implement this function without having to do a recursion dance, which is a bit useless since we already have all the flat locators in the API data structures. Might offer a little perf boost as well.

If you're interested to take a look, the API is defined in makeApi.ts, and in particular the idea would be to simply expose a function that would iterate over the packageRegistry keys to generate an array of locators and return it.

[arcanis]

Closing, as this should now be fixed as of #1838 - thanks for the help, @crubier! If you get the chance, can you confirm it fixes the perf impact on your side as well?