You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, SWC plugins can only receive static configuration options. However, plugins often need to behave differently based on the compilation context (e.g., server components vs client components, development vs production, ESM vs CJS)
Allow swc plugins to behave differently for Development and Prod
Allow swc plugins to behave differently for RSC and non RSC
...
Background
With the current implementation in packages/next/src/build/swc/options.ts, the configuration is static:
We could allow that the SWC plugin configurations accept a function that receives compile-time information, similar to Next.js's webpack configuration:
module.exports={experimental: {swcPlugins: [['plugin',({ serverComponents, development, esm })=>({// Dynamic configuration based on contexttransformServerComponents: serverComponents,}),],],},}
The function would receive an object containing relevant compile-time information such as:
serverComponents: boolean
development: boolean
esm: boolean
Other relevant context that's already available in the SWC options generation
The change required would be minimal - just checking if the options is a function and calling it with the context
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Goals
Currently, SWC plugins can only receive static configuration options. However, plugins often need to behave differently based on the compilation context (e.g., server components vs client components, development vs production, ESM vs CJS)
Background
With the current implementation in
packages/next/src/build/swc/options.ts
, the configuration is static:This makes it difficult to implement plugins that need to adapt their behavior based on the compilation context
For example throwing once the user tries to use a custom RSC feature outside of RSC
In our case we would be able to solve next-yak: Using next-yak converts server components to client components #112
Proposal
We could allow that the SWC plugin configurations accept a function that receives compile-time information, similar to Next.js's webpack configuration:
The function would receive an object containing relevant compile-time information such as:
serverComponents
: booleandevelopment
: booleanesm
: booleanThe change required would be minimal - just checking if the options is a function and calling it with the context
next.js/packages/next/src/build/swc/options.ts
Lines 106 to 108 in 9010e45
would change to:
Beta Was this translation helpful? Give feedback.
All reactions