Is there a reasonable way to run transforms like this on the output after module resolution is complete?

[spalger]

I'm looking to write a custom swc plugin to aid in some caching and front-end optimization we have, but need to apply my plugin to the output that vite is going to send to the browser after module resolution has completed and the absolute urls are placed in the import statements. It feels like this plugin could still do it's work just as effectively at that stage of the process, and would be much more efficient than doing a second swc transform with an output plugin or something.

Does anyone with enough experience about how vite and this plugin work know if this is really feasible? Should we just eat the cost of doing a second swc transform if the optimization is really worth it?

[ArnaudBarre]

The builtin import transformation plugin runs very late in the pipeline, I'm not 100% you can run a plugin after that.
Also I think this plugin can only work on JS files, so you would need to run SWC first for the pipeline to work (to remove TS and JSX).

Probably @sapphi-red have a deeper knowledge but running something after the import transformation is not usual.

Are you doing this only for performance issues? If so what are you current performance bottleneck? With rolldown-vite you can already get quite a fast startup that caching can become unnecessary.

In my testing with "normal" Vite the SWC transform is not the bottleneck so caching this is not very effective (I experimented but never added it because of the low global speedup)

[spalger]

It makes sense that using swc before bundling is actually important – I forgot about type-stripping being a critical pre-processing step.

Our goal is to wrap our lazy component loading so that we can cache the imports and synchronously resolve to the imported component after it has been imported once and skip the re-render triggered by always getting a promise, even from a cached module load. It's not a big deal, we'll probably just use a linter to ensure that people use absolute import strings in these cases and then extract the import string from the source.

[ArnaudBarre]

Maybe you can write a runtime caching of import promises with something like this (not tested):

const cache = new (Weak)Map();
const lazyWithCache = (fn: () => Promise) => {
  const cached = cache.get(fn);
  if (cached) return cached;
  const promise = React.lazy(fn);
  promise.then(module => {
    cache.set(fn, module)
  })
  return promise
}

[spalger]

Yeah, that would probably be enough for most scenarios, but we have a number of cases where a module is being imported from several locations and we would love for the cache to resolve all of those to the cached instance too, but the instances of the loader functions are different in those cases