Describe the feature
Currently, many modern bundlers can operate in non-Node.js environments (e.g., Browsers, Edge Workers, or WASM-based runtimes). Examples include Rollup, Rolldown (through WASM), Rspack (through WASM) and Vite (v7-, community).
In these environments, the standard node:fs module is unavailable. This creates a significant hurdle for plugins that need to access the file system (e.g., reading tsconfig.json, package.json, or checking file existence within the load or transform hooks). Since unplugin aims to provide a unified interface, it would be highly beneficial to abstract file system access to ensure plugins remain environment-agnostic.
Current Landscape
Several major bundlers already provide an abstract FS interface through the plugin context:
| Bundler |
Abstract FS Support |
Notes |
| Rollup |
✅ this.fs |
User-configurable via fs option |
| Rolldown |
✅ this.fs |
FS is configurable via an exposed memfs instance in browser build |
| Vite |
✅ Supported |
Compatible with Rollup/Rolldown context |
| Webpack |
✅ this.fs |
User-configurable via inputFileSystem |
| Rspack |
✅ this.fs |
Experimental support via inputFileSystem |
| Farm |
❌ No |
|
| Esbuild |
❌ No |
WASM build exists, but no native FS abstraction for plugins |
| Bun |
❌ No |
|
Proposed Solution
I propose that unplugin introduces a standardized fs object to the plugin context (e.g., this.fs or via the hook arguments).
This interface should ideally mimic a subset of the node:fs API (like readFile, stat, lstat) that the underlying bundler provides. For bundlers that do not yet support an abstract FS, unplugin could provide a transparent fallback to node:fs when running in Node.js.
Benefit
- Portability: Plugins will work out-of-the-box in Web-based IDEs (like StackBlitz), WASM-powered tools, and standard Node.js environments.
- Consistency: Developers won't need to write conditional logic to check if they are in a Node.js environment before performing simple I/O tasks.
Additional information
Describe the feature
Currently, many modern bundlers can operate in non-Node.js environments (e.g., Browsers, Edge Workers, or WASM-based runtimes). Examples include Rollup, Rolldown (through WASM), Rspack (through WASM) and Vite (v7-, community).
In these environments, the standard
node:fsmodule is unavailable. This creates a significant hurdle for plugins that need to access the file system (e.g., readingtsconfig.json,package.json, or checking file existence within theloadortransformhooks). Sinceunpluginaims to provide a unified interface, it would be highly beneficial to abstract file system access to ensure plugins remain environment-agnostic.Current Landscape
Several major bundlers already provide an abstract FS interface through the plugin context:
this.fsfsoptionthis.fsmemfsinstance in browser buildthis.fsinputFileSystemthis.fsinputFileSystemProposed Solution
I propose that
unpluginintroduces a standardizedfsobject to the plugin context (e.g.,this.fsor via the hook arguments).This interface should ideally mimic a subset of the
node:fsAPI (likereadFile,stat,lstat) that the underlying bundler provides. For bundlers that do not yet support an abstract FS,unplugincould provide a transparent fallback tonode:fswhen running in Node.js.Benefit
Additional information