Improve resolve performance with many files

[marvinhagemeister]

The version 4.1.1 of tsconfig-paths includes a performance fix, that can improve resolve speed by 10-20% in repositories with many files in of our projects.

See: dividab/tsconfig-paths#225

[codecov]

Codecov Report

Base: 95.27% // Head: 95.27% // No change to project coverage 👍

Coverage data is based on head (237df0e) compared to base (6304ddc).
Patch has no changes to coverable lines.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2654   +/-   ##
=======================================
  Coverage   95.27%   95.27%           
=======================================
  Files          68       68           
  Lines        2966     2966           
  Branches     1008     1008           
=======================================
  Hits         2826     2826           
  Misses        140      140           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[marvinhagemeister]

It looks like the tests on node 4 in macOS in Travis CI are failing. Is this something that should still be supported? Just checked and the latest major of eslint itself has the following minimum node version requirements:

• Node.js 12.22 and above
• Node.js 14 and above
• Node.js 16 and above

[ljharb]

Yes, absolutely. We support down to eslint v2.

[ljharb]

This is a duplicate of #2447, and is also a breaking change.

The best way to get this improvement into this project is for tsconfig-paths to backport it to v3.

[marvinhagemeister]

Thanks for the quick reply! Interesting, that's not a choice I would've made. I think in this particular case arguing multiple projects to backport PRs is an uphill battle, so in my case it looks like forking is the better option.

[ljharb]

Why would it be multiple projects? Isn't it just tsconfig-paths?

[marvinhagemeister]

As explained in #2447 the issue is that json5 upped their minimum required node version. The tsconfig-paths package is based on json5 because tsconfig.json can contain comments.

It's very unlikely that json5 will revert that decision and even if they did, it would require another update to tsconfig-paths. I feel like that is a big ask of developers to spend energy on node 4 support, given that it was EOL'ed in 2018 and contains known security vulnerabilities.

[ljharb]

They're certainly allowed to not spend that energy, but I will continue to do so.

[kibertoad]

@ljharb Why support old Node.js versions? People running such old runtimes are unlikely to update their libraries either.

[ljharb]

@kibertoad thats not true; it’s easy to update deps and very hard in many cases to update node itself.

[kibertoad]

@ljharb Newer dependencies for anything major in most cases don't support old Node versions. There are exceptions, like Express.js which is notorious for being bullish on old Node, but those are fairly rare, everyone else at least use ES6 features and often async/await

And teams that don't update Node more often than not don't touch "proven working" dependencies either, unless strictly needed. Eslint hardly qualifies as a critical update for legacy codebases.

[BPScott]

tsconfig-paths has shown to be amenable to backporting features to v3.

In dividab/tsconfig-paths#264 I've proposed backporting the performance fix that triggered this PR so hopefully eslint-plugin-import can take advantage of it.

[JounQin]

Welcome @BPScott ! And your backport PR is also great!