-
|
I'm using redo as a build system, which wants to know which files were involved in a build so it knows when the build should be rerun. Is there some way to list all test files (like It doesn't need to be statically generated through a command like export function sourceFilesPlugin(options?: SourceFilesPluginOptions): Plugin {
options ??= {};
options.depsFile ??= ".build.deps";
return {
name: "source-files-list",
generateBundle(opts, bundle) {
const sourceFiles = new Set();
for (const chunk of Object.values(bundle)) {
if (chunk.type === "chunk") {
// Add all modules in this chunk
for (const id of Object.keys(chunk.modules)) {
// Filter out virtual modules and node_modules if desired
if (!id.startsWith("\0") && !id.includes("node_modules")) {
const publicPath = `public${id}`;
sourceFiles.add(hasAccessSync(publicPath) ? publicPath : id);
}
}
}
}
// Write to a file
fs.writeFileSync(
path.resolve(opts.dir!, `../${options.depsFile}`),
Array.from(sourceFiles).join("\n").concat("\n"),
);
},
} satisfies Plugin;
} |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
I don't think Vitest has a built-in command that prints the whole transitive module graph for a test run, but you can get very close by logging what Vite actually transforms while Vitest is running. A small plugin is usually enough: // vitest.config.ts
import { defineConfig } from "vitest/config"
import { writeFileSync } from "node:fs"
function writeVitestDeps() {
const files = new Set<string>()
return {
name: "write-vitest-deps",
enforce: "post" as const,
transform(_code: string, id: string) {
const clean = id.split("?")[0]
if (clean && !clean.includes("/node_modules/") && !clean.startsWith("\0")) {
files.add(clean)
}
return null
},
buildEnd() {
writeFileSync(".test.deps", [...files].sort().join("\n") + "\n")
},
}
}
export default defineConfig({
plugins: [writeVitestDeps()],
})Then run your normal Vitest command and read A couple of caveats: this is a runtime-loaded list, so it includes setup files/helpers and only modules that were actually reached by that run. If you use multiple projects or many workers, you may want to write one file per project/worker and merge them afterwards. For a redo-like workflow, though, the runtime list is often more useful than a static import graph. |
Beta Was this translation helpful? Give feedback.
I don't think Vitest has a built-in command that prints the whole transitive module graph for a test run, but you can get very close by logging what Vite actually transforms while Vitest is running.
A small plugin is usually enough: