Uh oh!
There was an error while loading. Please reload this page.
Resolve paths for views asynchronously - #2653
Conversation
dougwilson
commented
May 18, 2015
Nice! Anyway we can add to this a way to prevent stampeding (which the sync version protected from) to the default lookup implementation? |
aredridel
commented
May 18, 2015
Oh, yes! I think I could work that in. |
aredridel
commented
May 18, 2015
Updated. |
a048a24 to
4de612fCompare5f268a4 to
9848645Comparegabrielcsapo
commented
Jun 16, 2016
👍 |
eb10dba to
340be0fComparebjohansebas
commented
Mar 27, 2025
Hey, @aredridel could you rebase this PR, please? |
bjohansebas
commented
May 29, 2025
@expressjs/express-collaborators @wesleytodd@UlisesGascon Any objections to releasing this in the next minor version of Express? |
ffeab94 to
68a40c3Comparejonchurch
commented
Jan 5, 2026
Does someone want to own last mile on this? Its in my list of stuck PRs, so either working to understand and land, or understand and close Im unassigning @blakeembrey bc its been so long idk why I assigned it to him and I doubt he does either the (current) test fails are unrelated to the PR |
bjohansebas
commented
Jan 5, 2026
It’s been a long time since the last time I reviewed it, I’d like to take another look in case I missed something. I’ll put it on my TODO list. |
68a40c3 to
3dd0d30Comparebjohansebas
commented
Jul 13, 2026
A few things I changed were:
On top of that, I added a couple of improvements beyond the original implementation:
Overall, the goal of these changes was to avoid introducing breaking changes while still improving the implementation. |
This eliminates the only post-startup synchronous I/O in Express.
In addition, this makes the view.lookup method non-private, intended to be used
by view engines to resolve paths to partials, and, if the View class is
extended, could be used for other resources such as internationalized messages.