Can the module graph in the dev server be enumerated?

[webJose]

Hello, everyone.

I have this need to invalidate previous resolutions done by my plug-in's resolveId hook. However, I cannot locate them inside server.moduleGraph using server.moduleGraph.getModuleById. Doing server.moduleGraph.invalidateAll() does the job, so I'm thinking that there must be a way to locate the modules I resolved previously, but without being able to examine the contents of server.moduleGraph, I have no idea how to troubleshoot this one.

Just in case I'm falling into the X->Y problem, here's my original problem: My plug-in externalizes certain module ID's, and on-demand it can be requested to "undo" those resolutions because the resolution data changed.

Without server.moduleGraph.invalidateAll(), my plug-in is not asked to resolve the ID's again. This is why I'm fixated on the module graph at the moment.

[ryanportfolio]

EnvironmentModuleGraph exposes two public maps you can loop over, idToModuleMap and urlToModuleMap:

configureServer(server) {
  // Vite 6+: server.environments.client.moduleGraph is the real graph.
  // server.moduleGraph is the old mixed client+ssr one kept for back-compat.
  for (const [id, mod] of server.environments.client.moduleGraph.idToModuleMap) {
    console.log(id, mod.file, mod.type)
  }
}

getModuleById misses because it only strips the ?t= timestamp, then does a plain map lookup. Your id has to match the stored one exactly: same \0 prefix, query, and leading-slash vs fs-path form. From a file path, getModulesByFile(file) is easier to hit.

But the likely cause: externalized ids (external: true) generally never become graph nodes, so there's nothing to find by id. That's why only invalidateAll() does anything.

To re-run resolveId on demand: it fires from the importer's transform, not the target. Save the importer:

const importersById = new Map() // externalizedId -> Set<importerId>

resolveId(id, importer) {
  if (shouldExternalize(id) && importer) {
    let set = importersById.get(id)
    if (!set) importersById.set(id, (set = new Set()))
    set.add(importer)
    return { id, external: true }
  }
}

Then invalidate just those importers instead of the whole graph:

const graph = server.environments.client.moduleGraph
for (const importerId of importersById.get(changedId) ?? []) {
  const mod = graph.getModuleById(importerId)
  if (mod) graph.invalidateModule(mod)
}
server.ws.send({ type: 'full-reload' })

invalidateModule clears the importer's transform result and walks its importers, so the next request re-transforms it and re-runs your resolveId. Targeted invalidateAll().

on Vite 6+ resolveId runs per environment, so that map mixes client and ssr ids unless you key it per environment

[Adham-Kiwan]

This is a great question, and your instinct to step back and look out for the X->Y problem is spot on. You have hit a very specific, nuanced behavior in how Vite caches module resolutions.

Here is exactly why you cannot find those modules, and how to fix your underlying problem without resorting to the nuclear invalidateAll() option.

Why getModuleById is failing you

When your resolveId hook marks a module as external (or resolves it to a bare external import), Vite often skips creating a standard ModuleNode for it in the server.moduleGraph. Because Vite doesn't have to transform, process, or serve the source code of an externalized module, it doesn't track it in the graph the same way it tracks your internal source files.

Therefore, searching for that specific external ID using getModuleById returns undefined.

The X->Y Solution: Invalidate the Importer, not the Importee

To get Vite to re-trigger your resolveId hook for those specific IDs, you need to understand where Vite caches that information.

Vite caches the result of a module resolution on the module that requested it (the importer). For example, if Component.jsx imports my-virtual-module (which you externalize), Vite caches that external resolution on the ModuleNode for Component.jsx.

To force Vite to "forget" the resolution and ask your plugin again, you must invalidate the importer module, not the external ID.

How to implement this in your plugin

You can achieve this by keeping a lightweight map of which modules import the IDs you care about during the resolveId phase, and then invalidating those specific importers when your resolution data changes.

Here is an example of how to structure that:

export default function myExternalResolverPlugin() {
  // Store a mapping of: TargetID -> Set of Importer IDs
  const importerMap = new Map();
  let viteServer;

  return {
    name: 'vite-plugin-dynamic-external',
    
    configureServer(server) {
      // Keep a reference to the server so we can access the moduleGraph later
      viteServer = server;
    },

    resolveId(source, importer) {
      // 1. Check if this is a module your plugin handles
      if (source === 'my-dynamic-module') {
        
        // 2. Track the importer so we can invalidate it later
        if (importer) {
          if (!importerMap.has(source)) {
            importerMap.set(source, new Set());
          }
          importerMap.get(source).add(importer);
        }

        // 3. Return your external resolution
        return { id: source, external: true }; 
      }
      return null;
    },

    api: {
      // A custom method you can call when your resolution data changes
      undoExternalization(targetSource) {
        if (!viteServer || !importerMap.has(targetSource)) return;

        const importers = importerMap.get(targetSource);

        for (const importerId of importers) {
          // Find the ModuleNode of the file that IMPORTED the external module
          const importerNode = viteServer.moduleGraph.getModuleById(importerId);
          
          if (importerNode) {
            // Invalidate the importer. 
            // The next time the browser requests this importer, Vite will re-transform it
            // and re-trigger resolveId for all of its imports!
            viteServer.moduleGraph.invalidateModule(importerNode);
          }
        }

        // Clear the tracking set for this target now that it's invalidated
        importers.clear();
      }
    }
  };
}

[3ni8ma]

Yes — in the dev server, you can access the module graph through server.moduleGraph:

import type { Plugin } from "vite"

export function myPlugin(): Plugin {
  return {
    name: "module-graph-enumerator",
    configureServer(server) {
      // Iterate all known modules
      server.moduleGraph.forEachModule((mod) => {
        console.log(mod.url, mod.id, mod.file)
      })

      // Get specific module by URL
      const mod = server.moduleGraph.getModuleByUrl("/src/main.tsx")

      // Get all modules imported by a given module
      const importers = mod?.importers  // modules that import this
      const imports = mod?.importedModules  // modules this imports
    }
  }
}

moduleGraph is a ModuleGraph instance with:

• forEachModule(fn) — iterate all modules in the graph
• getModuleByUrl(url) — lookup by resolved URL
• getModuleById(id) — lookup by module ID
• Each module node has .importers, .importedModules, .file, .url, .id, .transformResult, and .ssrTransformResult

For watching, the watcher is available on server.watcher (chokidar instance).