We Keep Coding

Inconsistent behavior when Babel is run through Babel Loader [duplicate]

After running my code through webpack it contians arrow functions. I need the code to work in ie11 so I need to get rid of the arrow functions.
I'm using babel-loader for all .js files.
I wrote a loader to check code for arrow functions and ran it after the babel-loader and didn't get any arrow functions, so I know the output from babel is good.
I've also tried babel-polyfill and the babel plugin for transforming arrow funtions.
As I know the babel-loader outputs good code I suspect it might be a plugin, but I can't just disable them to test as that breaks the build.
Webpack plugins used in dev:
plugins: [
new webpack.DefinePlugin({
'process.env': require('../config/dev.env')
}),
new webpack.HotModuleReplacementPlugin(),
new webpack.NamedModulesPlugin(), // HMR shows correct file names in console on update.
new webpack.NoEmitOnErrorsPlugin(),
// https://github.com/ampedandwired/html-webpack-plugin
new HtmlWebpackPlugin({
filename: 'index.html',
template: 'index.html',
inject: true
}),
// copy custom static assets
new CopyWebpackPlugin([
{
from: path.resolve(__dirname, '../static'),
to: config.dev.assetsSubDirectory,
ignore: ['.*']
}
])
]
The problem also appears in prod as well, but fixing it in dev should tell me how to fix it in prod as well.
I don't know of anywhere else the arrow function could be coming from, so I expect to, in essence, get code that works on ie11, but there's arrow functions coming from somewhere so it doesn't work.
It's not my code, so I can't just post it all. I can, however, post relevant snippets, but I don't know where the problem is so I don't know what's relevant yet.

I had the same problem and found the cause and solution.
Cause
babel-loader converts the grammar of es6 and higher to es5. However, because the conversion is done by the loader, the conversion occurs only in each file before it is bundled.
After the loader completes the conversion, webpack starts to bundle. However, webpack does not care about target version of babel-loader when it bundles files. It just bundles file with grammar of it's default ECMA version(which could be es6 or later). It was the reason why bundled result includes es6 grammar such as arrow function.
Initial Step
file1 (es6)
file2 (es6)
file3 (es6)
After loader works
file1' (es5)
file2' (es5)
file3' (es5)
After webpack bundles files
bundled file (es6)
Solution
You can just simply add target: "es5" in webpack.config.js to handle this. After that, webpack bundles file in grammar of es5
// .babelrc
{
"presets": ["#babel/preset-env"]
}
// webpack.config.js
module: {
...
target: "es5", // include this!!
loaders: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: 'babel-loader',
}
]
}
In webpack 5:
module.exports = {
target: ['web', 'es5']
}
target is positioned at the root of the config schema and needs to know whether it targets a node or web environment
References:
https://webpack.js.org/configuration/target/
Webpack 5 "dependOn" and target: "es5" appear to be incompatible

You can use babel. Since arrow functions comes with es6 , you can use babel to convert es5. Also this link could help to Webpack not converting ES6 to ES5.
Given below webpack config is what I used for babel.
module: {
loaders: [
{
test: /\.(js|jsx)$/,
exclude: /node_modules/,
loader: 'babel-loader',
options: {
babelrc: false,
presets: ["#babel/preset-env", "#babel/preset-react","es2015"]
}
}
]
}

Why webpack doesn't tree-shake the lodash when using "import * as _"?

I am learning about tree-shaking with a webpack 4/React application that uses Lodash.
At first, my Lodash usage looked like this:
import * as _ from "lodash";
_.random(...
I soon learned, via the BundleAnalyzerPlugin, that the entirety of Lodash was being included in both dev and prod builds (527MB).
After googling around I realized that I needed to use a specific syntax:
import random from "lodash/random";
random(...
Now, only random and it's dependencies are correctly included in the bundle, but I'm still a little confused.
If I need to explicitly specify functions in my import statement, then what role is the tree-shaking actually playing?
The BundleAnalyzerPlugin isn't showing a difference in payload size when comparing between dev and production mode builds (it's the correct small size in both, but I thought that tree-shaking only took place with production builds?).
I was under the impression that TreeShaking would perform some sort of static code analysis to determine which parts of the code were actually being used (perhaps based on function?) and clip off the unused bits.
Why can't we always just use * in our import and rely on TreeShaking to figure out what to actually include in the bundle?
In case it helps, here is my webpack.config.js:
const path = require("path");
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer").BundleAnalyzerPlugin;
module.exports = {
entry: {
app: ["babel-polyfill", "./src/index.js"]
},
plugins: [
new BundleAnalyzerPlugin({
analyzerMode: "static",
openAnalyzer: false
})
],
devtool: "source-map",
output: {
filename: "[name].js",
path: path.resolve(__dirname, "dist"),
chunkFilename: "[name].bundle.js",
publicPath: ""
},
module: {
rules: [
{
test: /\.js$/,
loader: "babel-loader",
include: /src/,
options: {
babelrc: false,
presets: [
[
"env",
{
targets: {
browsers: ["last 2 Chrome versions"]
}
}
],
"#babel/preset-env",
"#babel/preset-react"
],
plugins: ["syntax-dynamic-import"]
}
},
{
test: /\.(ts|tsx)$/,
use: [
{
loader: require.resolve("ts-loader"),
options: {
compiler: require.resolve("typescript")
}
}
]
}
]
},
resolve: {
symlinks: false,
extensions: [".js", ".ts", ".tsx"],
alias: {
react: path.resolve("./node_modules/react")
}
}
};
I'm invoking webpack with webpack --mode=development and webpack --mode=production.

All two existing answers are wrong, webpack do treeshake import *, however that only happens when you're using a esmodule, while lodash is not. The correct solution is to use lodash-es
Edit: this answer only applies to webpack4, while webpack 5 supported a limited subset of tree shaking for commonjs, but I haven't tested it myself

Actually, it is not related to the Webpack ability to tree-shake. base on Webpack docs about tree-shaking
The new webpack 4 release expands on this capability with a way to provide hints to the compiler via the "sideEffects" package.json property to denote which files in your project are "pure" and therefore safe to prune if unused
When you set the "sideEffects: false on your package.json based on the linked docs:
All the code noted above does not contain side effects, so we can simply mark the property as false to inform webpack that it can safely prune unused exports.
If you have some files or packages which you know they are pure add them to sideEffects to prune it if unused. There are some other solutions to do tree-shaking that I proffer to read the whole article on Webpack docs.
One of the manual ways are using direct importing like below:
import get from 'lodash/get';
That Webpack understands add just get from the whole lodash package. another way is destructing importing that needs some Webpack optimization for to tree-shaking, so you should import like below:
import { get } from 'lodash';
Also, another tricky way is just to install a specific package, I mean:
yarn add lodash.get
OR
npm install --save lodash.get
Then for import just write:
import get from 'lodash.get';
Definitely, it is not tree-shaking, it is a tight mindset development, but it causes you just add what you want.
BUT
YOU DON'T DO ANYTHING OF ABOVE SOLUTIONS, you just add the whole package by writing import * as _ from "lodash"; and then use _.random or any function and expect Webpack understand you wanna the tree-shaking be happening?
Surely, the Webpack works well. you should use some configs and coding style to see the tree-shaking happens.

If you're already using Babel, the easiest method to properly tree shake lodash is to use the official babel-plugin-lodash by the lodash team.
This uses Babel to rewrite your lodash imports into a more tree-shakeable form. Doing this dropped my team's bundle size by ~32kB (compressed) with less than 5 minutes of effort.

How to get Webpack to use already existing source maps when generating source maps?

I have JavaScript code and source maps generated from TypeScript code (using tsc).
I then have a second compilation step which bundles the code using webpack.
I have enabled source maps in webpack.config.js:
module.exports = {
devtool: "source-map"
}
The generated source map isn't entirely right.
Webpack is not taking into account the existing source maps that have been generated from TypeScript code.
This results in a mapping to the JavaScript code instead of the TypeScript code.
How can I get the Webpack source map to include existing mapping?
EDIT:
After renaming my question, and searching for my renamed question on Google, I found an answer.
You can use a preloader with webpack called source-map-loader: https://webpack.js.org/loaders/source-map-loader/
However, after installing source-map-loader and updating webpack.config.js to the following, the existing source maps are still not used:
module.exports = {
devtool: "source-map",
module: {
rules: [
{
test: /\.js$/,
use: ["source-map-loader"],
enforce: "pre"
}
]
}
}
My guess is that because the files my existing source map point to are located outside the entry directory in webpack.config.js, they are ignored...?

If you transpile the typescript as part of webpack, you will get the source maps with it.
devtool: 'source-map',
module: {
rules: [
{
test: /\.ts$/,
exclude: /node_modules/,
use: ([
{
loader: 'awesome-typescript-loader',
options: { configFileName: 'tsconfig.json' }
},
you need devTool: 'source-map' in webpack
and the "sourceMap": true in tsconfig.json
devtool: 'cheap-module-eval-source-map',
provides a faster build to generate source maps in development. But it will put the source mapping inline. So not for production.
So the big question. Why have a step separated from webpack?
If you use AOT compilation with angular (with the ngc command from #anguler/compiler), and produce .map files in the aot folder, then you want to reuse the map files. I can tell you I tested it to work with the solution below.
Then this will make it work:
{
test: /\.js$/,
use: ["source-map-loader"],
enforce: "pre"
},
And it is important you have sourceMap: true in tsconfig, and in the minimizer if you use one:
optimization: {
minimizer: [
new TerserPlugin({
cache: true,
parallel: true,
sourceMap: true, // Must be set to true if using source-maps in production
terserOptions: {
// https://github.com/webpack-contrib/terser-webpack-plugin#terseroptions
}
I have a tsconfig.json in development
a tsconfig_ao1.json for ngc command
I have a tsconfig_ao2.json to compile with aot the main.ts using the aot folder. And I use ngc outside of webpack because I could not use #ngtools/webpack inside webpack without issues.
If you are doing something else, you ened to understand the source-map-load will only load source maps if the files it test matches has source maps, and if the files art part of the tree loaded from the entry. There must be an import from the main.ts to the file that is source mapped.

Using Vue in Laravel

I am new to Vue but I thought I'd give it a go in a recent project, I can see why its liked. Anyway, everything was going great until I switched over to IE, where nothing worked at all.
With errors such as Object doesn't support property or method 'assign' I gave it a Google and apparently IE doesn't support ES6 very well, according to this question: Getting Error: Object doesn't support property or method 'assign'
So, I'd heard of Babel and it looked like the sort of thing that would do the job as it is capable of converting from ES6. Following this I attempted to integrate Babel into my Laravel project.
I updated my webpack.min.js as follows:
let mix = require('laravel-mix');
/*
|--------------------------------------------------------------------------
| Mix Asset Management
|--------------------------------------------------------------------------
|
| Mix provides a clean, fluent API for defining some Webpack build steps
| for your Laravel application. By default, we are compiling the Sass
| file for the application as well as bundling up all the JS files.
|
*/
mix.js('resources/assets/js/app.js', 'public/js')
.webpackConfig({
module: {
rules: [{
test: /\.jsx?$/,
exclude: /node_modules/,
use: {
loader: 'babel-loader',
options: {
presets: ['env']
}
}
}]
}
})
.sass('resources/assets/sass/app.scss', 'public/css');
if (!mix.inProduction()) {
mix.webpackConfig({
devtool: 'source-map'
})
.sourceMaps();
} else if (mix.inProduction()) {
mix.version();
}
mix.browserSync({
proxy: '127.0.0.1:8000'
});
The env package refers to: https://babeljs.io/docs/en/babel-preset-env
However, this did not seem to solve my problem.
Should I just use mix.babel instead?

You need a polyfill: https://babeljs.io/docs/en/babel-polyfill
Import that as the first line in your entry (app.js).
However, I'd recommend using vue cli instead of laravel mix entirely.

Babel not compiling vendors chuck

I migrated to Webpack 4 and set up everything according to the Docs, however, my vendors.js chunk is not getting compiled like the main.js chunk.
I have placed the vendors into the optimization.splitChunks.cacheGroups object, as the docs suggested, but didnt find a way to make these "cacheGroups" get compiled with babel.
My problem is that one of the libraries has a ES6 class and now IE11 isnt working due to this fact.
My webpack optimization object looks like:
optimization: {
splitChunks: {
cacheGroups: {
styles: {
name: 'styles',
test: /\.css$/,
chunks: 'all',
enforce: true
},
vendor: {
name: 'vendor',
test: /[\\/]node_modules[\\/]/,
chunks: 'all',
enforce: true
}
}
}
}
Is there a way to force webpack to compile vendors with babel as well?
Regards

you should have posted the entire webpack config to give people more context.
Anyways, optimization step has very little to do with the actual transpiling. Your vendor chunk is set to only include stuff from node_modules which is almost never processed (unless you specifically tell babel-loader to include a certain package).
Since I do not know how you configured your babel-loader I would suggest something along these lines:
{
test: /\.js$/,
exclude: (file) => {
return /node_modules/.test(file) && !file.includes("/node_modules/my-es6-module/");
}
}
The idea is to exclude all files containing node_modules unless the file path contains the name of your specific module which you do need to process with babel.
In general, having an ES6 code published to npm is a very bad practice and should be avoided at all costs.
If this is not enough, please do update your question with your webpack config to give us more insight into your setup.