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

Despite Babel configuration, Babel not being used #1098

Closed
hyperupcall opened this issue Dec 4, 2023 · 0 comments · Fixed by #1248
Closed

Despite Babel configuration, Babel not being used #1098

hyperupcall opened this issue Dec 4, 2023 · 0 comments · Fixed by #1248
Labels
p-low-priority t-enhancement This issues tracks a potential improvement to the software
Milestone

Comments

@hyperupcall
Copy link
Contributor

hyperupcall commented Dec 4, 2023

Describe the bug

While working on #879, I noticed that we have Babel installed, but do not use it. I explain how so below. In #879, I simply removed Babel to resolve this - if we aren't using it, and there are no issues, then maybe it should be good to remove?

But thinking about, I wanted to ask to be sure. For example, FormatJS has a Babel transform that purports to reduce the bundle size. If we remove Babel, then this can no longer be used.

Increasingly, like Webpack, people are moving away from Babel. Most supported browsers by web apps are evergreen browsers, and update quickly to support the latest features. In addition, TypeScript has options that will cause a compilation fail if modern features are used (say library methods from ES2023). If we remove Babel, that will make the compilation pipeline easier to understand, and we can still make sure develoeprs only use features supported by all modern browsers by configuring TypeScript.

Thoughts?

Expected behavior

To run babel-loader on our JavaScript files.

To Reproduce

We can see what loaders are being ran through a command line flag:

$ ./node_modules/.bin/webpack build --color --progress --mode development --profile --json=compilation-stats.json

Reading compilation-stats.json, Ctrl+f'ing for ts-loader, I read 657 instances such as:

...
	"issuerPath": [
		{
			"identifier": "/storage/ur/storage_home/Docs/Programming/Repositories/fox-forks/OED/node_modules/ts-loader/index.js!/storage/ur/storage_home/Docs/Programming/Repositories/fox-forks/OED/src/client/app/index.tsx",
			"name": "./src/client/app/index.tsx",
			...

But, no results show for babel-loader.

Looking at the webpack.config.js, the issue becomes apparent after reading the line:

{ test: /\/jsx?$/, exclude: /node_modules/, use:[{loader: 'babel-loader'}] }

The test regex matches no files, because it only runs on paths that end with /jsx. Even if that were fixed, there is only 1 JavaScript file (src/client/app/translations/data.js). This means that we will also have to configure babel-loader to be used after ts-loader, which looks something like:

{ test: /\.[jt]sx?$/, exclude: /node_modules/, use: ['babel-loader', 'ts-loader'] },
@hyperupcall hyperupcall changed the title Despite Babel configuration, Babel not being used. Despite Babel configuration, Babel not being used Dec 4, 2023
@huss huss added this to the 1.x milestone Mar 24, 2024
@huss huss added t-enhancement This issues tracks a potential improvement to the software p-low-priority labels Mar 24, 2024
@hyperupcall hyperupcall mentioned this issue May 29, 2024
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p-low-priority t-enhancement This issues tracks a potential improvement to the software
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants