Skip to content

[Feature Request]: Standardized Abstract File System Interface (this.fs) #593

Description

@guyutongxue

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

  • Would you be willing to help implement this feature?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions