Next.js dev restart cannot resolve generated S2 style macro macro-*.css imports unless .next is deleted

[squarepots]

Here’s a paste-ready issue draft.

Title

Next.js dev restart cannot resolve generated S2 style macro macro-*.css imports unless .next is deleted

🐛 Bug Report

React Spectrum S2 style macros work on a clean Next.js webpack dev cache, but after stopping and restarting next dev --webpack, Next fails to resolve generated macro-*.css imports.

Deleting .next/ and starting dev again makes the app compile. A normal dev-server restart without deleting .next/ brings the same module-not-found error back.

This appears related to .next/dev cache reuse across Next dev process restarts.

🤔 Expected Behavior?

A Next.js app using the documented React Spectrum S2 style macro setup should be restart-stable in development.

After running:

next dev --webpack

then stopping and starting it again, generated S2 macro CSS imports should still resolve without requiring deletion of .next/.

😯 Current Behavior

After a clean .next deletion, the app starts and renders correctly.

Then:

1. Stop pnpm dev
2. Run pnpm dev again
3. Open /

Next dev fails with:

Module not found: Can't resolve 'macro-b792116fea41d87b6258eed7146211dcbc2bca7f08b1c4cf78bb73166e7c8b85.css'
./src/Header/Nav/index.tsx (184:1)

Module not found: Can't resolve 'macro-b792116fea41d87b6258eed7146211dcbc2bca7f08b1c4cf78bb73166e7c8b85.css'
  182 | };
  183 |
> 184 | import "macro-b792116fea41d87b6258eed7146211dcbc2bca7f08b1c4cf78bb73166e7c8b85.css";
      | ^
  185 | import "macro-d8acfac27468f32f111d6447833c3ff92beeda1b200a8e49227dd3cb89d421b6.css";
  186 | import "macro-261ed03a5acae99f2e79430c11a10f5627920488f69594975db2dc8dd5710781.css";
  187 | import "macro-b536612b4d5bd874f263998a5d054e39c7469ed07bbcefd0b99680b75b0cd01e.css";

https://nextjs.org/docs/messages/module-not-found

The same failure class can appear for other S2 macro-using files in the app shell, including header/footer/logo/homepage files.

After the failure, .next/dev exists, but the reported macro-*.css file is not present.

💁 Possible Solution

It looks like Next dev cache may retain transformed modules containing generated bare macro-*.css imports, while the macro plugin’s generated CSS module state is not restored or re-created on the next dev process start.

Possible areas to inspect:

• unplugin-parcel-macros generated CSS module handling across webpack dev restarts
• Next.js .next/dev cache reuse with macro-generated virtual CSS imports
• Whether the plugin needs to invalidate or regenerate macro CSS modules when cached transformed modules are reused

I am not sure whether the fix belongs in React Spectrum S2 macro output, unplugin-parcel-macros, or Next.js cache integration.

🔦 Context

We are migrating a customer-facing Next.js app to React Spectrum S2 as the baseline UI system. Production build and a clean dev cache can work, but local development is unreliable because every normal dev restart can reintroduce missing generated macro CSS imports.

This blocks normal browser-based frontend proof and makes it hard to tell whether UI issues are real or caused by stale generated macro assets.

We are intentionally trying to stay close to the documented S2/Next setup and avoid custom webpack resolver bridges or local CSS workarounds.

🖥️ Steps to Reproduce

Our app is not currently reduced to a minimal public repro, but the behavior is reproducible in our Next app with this setup:

next.config.ts shape:

import type { NextConfig } from 'next'
import macros from 'unplugin-parcel-macros'

const macroPlugin = macros.webpack()

type WebpackCssModule = {
  type?: string
  identifier?: () => string
}

const nextConfig: NextConfig = {
  webpack(config) {
    config.plugins.push(macroPlugin)

    config.optimization.splitChunks ||= {}
    config.optimization.splitChunks.cacheGroups ||= {}
    config.optimization.splitChunks.cacheGroups.s2 = {
      name: 's2-styles',
      test(module: WebpackCssModule) {
        const identifier = module.identifier?.() ?? ''
        return (
          (module.type === 'css/mini-extract' && identifier.includes('@react-spectrum/s2')) ||
          /macro-(.*?)\.css/.test(identifier)
        )
      },
      chunks: 'all',
      enforce: true,
    }

    return config
  },
}

export default nextConfig

Script:

{
  "dev": "next dev --webpack -p 3000 --hostname localhost",
  "build": "next build --webpack"
}

Repro sequence:

rm -rf .next
pnpm dev
# Open http://localhost:3000/ -> works
# Stop dev server
pnpm dev
# Open http://localhost:3000/ -> module-not-found for generated macro-*.css

The source files use S2 style macros like:

import { style } from '@react-spectrum/s2/style' with { type: 'macro' }

🌍 Your Environment

Version:

@react-spectrum/s2: 1.3.1
unplugin-parcel-macros: 0.2.0
next: 16.2.6
react: 19.2.6
react-dom: 19.2.6
node: 24.14.0
pnpm: 11.0.9

Browsers:

Chromium-based browser / Next.js dev overlay

Operating system:

Windows, PowerShell environment

🦄 Other

No custom webpack resolver bridge is currently used. We previously tested a custom resolver workaround and removed it because we want to stay with the official S2/Next macro setup.

🕷 Tracking Issue

No public tracking issue yet.

[squarepots]

I did some additional local investigation and found a more specific failure mechanism.

unplugin-parcel-macros appears to keep generated macro CSS assets in process memory:

let assets = new Map();
let assetsByFile = new Map();

The transform appends generated imports such as:

import "macro-b792116fea41d87b6258eed7146211dcbc2bca7f08b1c4cf78bb73166e7c8b85.css";

Those imports resolve only if the same process still has the generated asset in the in-memory assets map:

resolveId(id) {
  if (assets.has(id)) {
    return id;
  }
}

loadInclude(id) {
  return assets.has(id);
}

load(id) {
  return assets.get(id).content;
}

On a clean .next dev start, this works because the macro transform runs and fills the in-memory asset map.

After stopping and restarting next dev --webpack, Next/webpack restores previously transformed modules from .next/dev/cache/webpack/*.pack.gz. I confirmed by decompressing/searching those cache files that they contain the generated macro-b792...css import.

At that point, the new Node process has an empty assets map, but the restored transformed module still imports macro-b792...css. The plugin cannot resolve/load it, so Next throws module-not-found.

So the mismatch seems to be:

• Next webpack dev cache persists macro-transformed JS across process restarts.
• unplugin-parcel-macros does not persist the matching generated CSS assets across process restarts.
• The restored JS imports virtual/generated CSS that no longer exists in plugin memory.

In plain terms: Next remembers the transformed module on disk, but the generated CSS only existed in the previous process’s memory.

This makes deleting .next fix the next run because it forces webpack to rerun the macro transform and refill the in-memory asset map.

[squarepots]

Possible Solution: unplugin-parcel-macros should either persist generated CSS assets in a way Next can restore, or make webpack know that macro-transformed files cannot be reused without regenerating the CSS.