feat: experimental preTransformDynamicRequests

[patak-dev]

Description

@danielroe has been working to adopt the new warmup functionality from Vite 5 and review their warmup implementation.

This PR implements an idea we discussed. The current warmup, --open, and preTransformRequests will only crawl static imports. There are some dynamic imports in routes that frameworks know should be crawled but if all of them are added to warmup, there could be a lot of unneeded modules processed depending on the route the user is visiting. Interested in hearing your opinion on this one @bluwy.

preTransformDynamicRequests will let frameworks decide if a request that would be started by a dynamic import should be crawled or not.

I named the function preTransformDynamicRequests instead of preTransformDynamicImports because we are giving a URL to it, we can change the name.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[bluwy]

Another function-based option 😄 I'm trying to imagine the usecase but I'm not quite sure how it'll happen. For example, if it depends on the route the user is visiting, shouldn't the route would've statically import that url in the first place? Dynamic imports would always imply something optional.

Also would this be able to workaround by calling server.transformRequest manually, or would that incur a large perf impact if we don't support it directly? For example, if the framework detects that the user accesses a certain URL and it knows a certain url would be needed.

[patak-dev]

Another function-based option 😄 I'm trying to imagine the usecase but I'm not quite sure how it'll happen. For example, if it depends on the route the user is visiting, shouldn't the route would've statically import that url in the first place? Dynamic imports would always imply something optional.

So, for Nuxt, they will hit a dynamic import right away at the start of every route as that is how their router work. I'm still unsure if this API would be good though, @danielroe could check later if there is enough information to know if a dynamic import should be crawled. But it seems that isn't the case, I just looked at it with @antfu and all dynamic imports are going to be hit for each route so you don't know if you should process it or not.

Also would this be able to workaround by calling server.transformRequest manually, or would that incur a large perf impact if we don't support it directly? For example, if the framework detects that the user accesses a certain URL and it knows a certain url would be needed.

Yes, Nuxt was already doing this but more similar to what warmup is doing now. But ya, it looks like Nuxt will need to call requestTransform for the correct dynamic import when a page is hit in their server.

We also discussed with Anthony another use case for this PR, that could still be interesting. He is using dynamic imports to conditionally load some features that are not always needed like:

if (__FEATURE_FLAG__)
  import(...).then(...)

For these feature imports, the function will still be useful. But it may be too much of an edge case. For sli.dev for example where there are several of these, he doesn't care that all of them are loaded during dev so he will probably just adopt warmup.clientFiles for all the features.

[bluwy]

Thanks. Perhaps in the case of routing where each route is a dynamic import, it would also be tricky to use this API since the information of which page being requested doesn't exist in this hook/option. Nuxt might already have the mapping of route urls to the route files, that might be easier to call server.transformRequest directly 🤔

Maybe also, we could add a warmup option to server.transformRequest so it handles the error-reporting stuff and others OOTB, and so it's easier to use. But that's just an idea.

[bluwy]

@patak-dev should we close this over #14787, or there's still a possibility for this API?

[patak-dev]

Let's close this one until we have a real use case. Working with ecosystem partners to adopt warmupRequest seems like a good strategy moving forward.