Skip to content
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

Closed
Collinbrown95 opened this issue Aug 23, 2023 · 4 comments · Fixed by #1752
Closed

RSpack Lingui Example #1749

Collinbrown95 opened this issue Aug 23, 2023 · 4 comments · Fixed by #1752

Comments

@Collinbrown95
Copy link
Contributor

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?

@Collinbrown95 Collinbrown95 mentioned this issue Aug 23, 2023
12 tasks
@timofei-iatsenko
Copy link
Collaborator

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

Loader's configuration is aligned with the JS version of swc-loader (SWC plugins will be provided in future releases and are currently not supported).

😢

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.

@Collinbrown95
Copy link
Contributor Author

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: Uncaught ReferenceError: Plural is not defined.

My new rspack.config.js configuration is as follows:

/**
 * @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 README.md either way, but for now I'm wondering if we should proceed with everything in babel, then migrate entirely to swc-loader once plugins are supported? What do you think?

@timofei-iatsenko
Copy link
Collaborator

but I am getting the following error: Uncaught ReferenceError: Plural is not defined

Did you try to change the order of loaders? It seems SWC is executed before babel, but should be vice-versa.

then migrate entirely to swc-loader once plugins are supported

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.

@Collinbrown95
Copy link
Contributor Author

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 Napi Error: GenericFailure - TypeError: The argument 'id' must be a non-empty string. Received '', which I'm guessing is related to the interoperability between babel-loader and builtin:swc-loader?

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants