-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RSpack Lingui Example #1749
Comments
Yes, we would be interested. I started to write that we can use SWC plugin with built-in SWC loader, and keep RSpack as fast as possible without using babel, but than found
😢 Anyway, i would add this to the readme of example just to avoid another people to dig into documentation to understand why you need to use babel instead of built-in loader. BTW you can use babel only for macro transformation, and left all other transformations for faster built-in swc loader. I'm not sure how much faster it would be, but it seems the better approach than completely override it with babel. |
Thanks for the suggestion! I tried to offload the react and typescript transformations to swc-loader as you suggested, but I am getting the following error: My new /**
* @type {import('@rspack/cli').Configuration}
*/
module.exports = {
context: __dirname,
entry: {
main: "./src/main.tsx"
},
builtins: {
html: [
{
template: "./index.html"
}
]
},
module: {
rules: [
{
test: /\.svg$/,
type: "asset",
},
{
test: /\.tsx$/,
exclude: /node_modules/,
use: {
loader: 'babel-loader',
options: {
plugins: [
"macros"
],
}
}
},
{
test: /\.tsx$/,
use: {
loader: "builtin:swc-loader",
options: {
jsc: {
parser: {
syntax: "typescript",
jsx: true,
},
transform: {
react: {
pragma: "React.createElement",
pragmaFrag: "React.Fragment",
throwIfNamespace: true,
development: false,
useBuiltins: false,
},
},
},
},
},
type: "javascript/auto"
},
]
}
}; I'm wondering if there's a mistake in my configuration, or if something is going wrong when trying to split the work between babel and swc-loader? I'll add your suggested caveat to the |
Did you try to change the order of loaders? It seems SWC is executed before babel, but should be vice-versa.
I would definitely migrate entirely to native swc-loader once plugins are supported. This way zero js (which is single threaded) would be involved in compilation. But for now it's hard to say how much impact babel loader will make for bundling. Need to test either way. |
You're right, it looks like the order is right-to-left. I updated the config to reflect the new order. /**
* @type {import('@rspack/cli').Configuration}
*/
module.exports = {
context: __dirname,
entry: {
main: "./src/main.tsx"
},
builtins: {
html: [
{
template: "./index.html"
}
]
},
module: {
rules: [
{
test: /\.svg$/,
type: "asset",
},
{
test: /\.tsx$/,
exclude: /node_modules/,
use: [
{
loader: "builtin:swc-loader",
options: {
jsc: {
parser: {
syntax: "typescript",
jsx: true,
},
transform: {
react: {
pragma: "React.createElement",
pragmaFrag: "React.Fragment",
throwIfNamespace: true,
development: false,
useBuiltins: false,
},
},
},
},
},
{
loader: 'babel-loader',
options: {
plugins: [
"macros"
],
}
},
]
},
]
}
}; That did indeed resolve the original error, but now I get I'm open to debugging this further, but I also opened a PR here (#1752) for this example, in case you want to continue the discussion in the PR? |
I have a use case where Lingui-JS is used for i18n in combination with RSpack as a web bundler.
I recently worked through the Lingui React Example with some small adaptations so that RSpack was used as a bundler instead of webpack (see my rspack-lingui repo for the reference implementation).
Given that someone else might have a similar use cases, it might be helpful to have an rspack-lingui example in the examples folder of this repository.
Would you be interested in a PR to add the example described above to the examples folder?
The text was updated successfully, but these errors were encountered: