SWC plugin runner no longer provides full file path to metadata

[serg-and]

Link to the code that reproduces this issue

https://github.com/serg-and/nextjs-minimal-swc-plugin-issue

To Reproduce

npm i
cd swc_plugin
npm run prepublish
cd ..
npm run dev

Logs will show that the provided filename in the metadata no longer includes the file path, only the filename.

Current vs. Expected behavior

Next's pluggin runner no longer provides the known file path to the metadata for a SWC plugin, only providing the file name.

This is conflict with SWC, saying: swc docs

/// Host side metadata context plugin may need to access.
/// This is a global context - any plugin in single transform will have same
/// values.
pub struct TransformPluginMetadataContext {
    /// The path of the file being processed. This includes all of the path as
    /// much as possible.
    pub filename: Option<String>,

    ...
}

This breaks several packages such as next-superjson-plugin which rely on the path to determine whether some files are page or app router based.

Provide environment information

Operating System:
  Platform: linux
  Arch: arm64
  Version: #1 SMP Wed Jul 17 10:51:09 UTC 2024
  Available memory (MB): 7185
  Available CPU cores: 8
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 15.0.1 // Latest available version is detected (15.0.1).
  eslint-config-next: 15.0.1
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.0.4
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Pages Router, SWC

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

I believe the issue originates from here https://github.com/vercel/next.js/blob/v15.0.1/turbopack/crates/turbopack-ecmascript-plugins/src/transform/swc_ecma_transform_plugins.rs#L189

Some(ctx.file_name_str.to_string()) could simply be changed to Some(ctx.file_path_str.to_string())

[kdy1]

Investigation

https://github.com/swc-project/swc/blob/e6fc5327b1a309eae840fe1ec3a2367adab37430/crates/swc/src/config/mod.rs#L588-L592 is the cause.

[kdy1]

I did some extra investigation, and

next.js/crates/napi/src/transform.rs

Lines 99 to 123 in e9c4a75

	let options: TransformOptions = serde_json::from_slice(&self.options)?;
	let fm = match &self.input {
	Input::Source { src } => {
	let filename = if options.swc.filename.is_empty() {
	FileName::Anon
	} else {
	FileName::Real(options.swc.filename.clone().into())
	};
	self.c.cm.new_source_file(filename.into(), src.to_string())
	}
	Input::FromFilename => {
	let filename = &options.swc.filename;
	if filename.is_empty() {
	bail!("no filename is provided via options");
	}
	self.c.cm.new_source_file(
	FileName::Real(filename.into()).into(),
	read_to_string(filename).with_context(|| {
	format!("Failed to read source code from {}", filename)
	})?,
	)
	}
	};

is the direct cause. So, javascript is not passing the absolute path as filename option at first.

[kdy1]

Do you mean the absolute file path, or path from the project root?
Which one is the thing you need?

[serg-and]

Path from the project root was what was provided by previous versions of next, so that's what is need for backwards compatibility.

[awkaiser-tr]

Giving this a New Years bump! I see @kdy1 self-assigned, identified root cause, then recently unassigned? 😞

If the Next.js team has reasons this won't be patched, that would be great to know so projects such as next-superjson-plugin can be prompted to adapt. In the meantime, folks impacted by this have been unable to upgrade their Next.js projects beyond v14 for 109 days now and it feels bad to be held back by something so small. The issue can be resolved a few different ways¹² but, if it makes no difference to Next.js itself, here at the root cause would be the best patch location.

Footnotes

1. Suggestion to change next-superjson-plugin behavior ↩

2. Suggestion to use next-superjson instead ↩