},
module: {
rules: [
{
test: /.(js|jsx)$/,
use: ‘babel-loader’,
},
],
},
plugins: [
new webpack.optimize.UglifyJsPlugin(),
new HtmlWebpackPlugin({ template: ‘./src/index.html’ }),
],
};
module.exports = config;
Node API
即便使用 Node API，用户也应该在配置中传入 plugins 属性。compiler.apply 并不是推荐的使用方式。
// some-node-script.js
const webpack = require(‘webpack’); //访问 webpack 运行时(runtime)
const configuration = require(‘./webpack.config.js’);
let compiler = webpack(configuration);
compiler.apply(new webpack.ProgressPlugin());
compiler.run(function (err, stats) {
// …
});
以上看到的示例和webpack 自身运行时(runtime) 极其类似。webpack 源码 中隐藏有大量使用示例，你可以用在自己的配置和脚本中。
在每次编译代码时，手动运行 npm run build 会显得很麻烦。
webpack 提供几种可选方式，帮助你在代码发生变化后自动编译代码：
-
webpack watch mode(webpack 观察模式)
-
webpack-dev-server
-
webpack-dev-middleware
大多数场景下我们会使用 webpack-dev-server
使用 watch mode(观察模式)
你可以指示 webpack “watch” 依赖图中所有文件的更改。如果其中一个文件被更新，代码将被重新编译，所以你不必再去手动运行整个构建。
启动 webpack watch mode
webpack --watch
如果能够自动刷新浏览器就更好了，因此可以通过 browser-sync 实现此功能。
缺点: 每次编译都要读写磁盘
使用 webpack-dev-server
webpack-dev-server 为你提供了一个简单的 web server，并且具有 live reloading(实时重新加载) 功能。
安装
npm i webpack-dev-server -D
// webpack.config.js
module.exports = {
devServer: {
// 当使用内联模式(inline mode)时，控制台(console)将显示消息，可能的值有 none, error, warning 或者 info（默认值）。
clientLogLevel: ‘none’,
//当使用 HTML5 History API 时，任意的 404 响应都可能需要被替代为 index.html
historyApiFallback: {
index: index.html,
},
// 启用 webpack 的模块热替换特性
hot: true,
// 告诉服务器从哪里提供内容。只有在你想要提供静态文件时才需要。我们这里直接禁用掉
contentBase: false,
// 一切服务都启用gzip 压缩：
compress: true,
// 指定使用一个 host。默认是 localhost
host: ‘localhost’,
// 指定要监听请求的端口号
port: ‘8000’,
// local服务器自动打开浏览器。
open: true,
// 当出现编译器错误或警告时，在浏览器中显示全屏遮罩层。默认情况下禁用。
overlay: false,
// 浏览器中访问的相对路径
publicPath: ‘’,
// 代理配置
proxy: {
‘/api/’: {
target: ‘https://github.com/’,
changeOrigin: true,
logLevel: ‘debug’,
},
},
// 除了初始启动信息之外的任何内容都不会被打印到控制台。这也意味着来自 webpack 的错误或警告在控制台不可见。
// 我们配置 FriendlyErrorsPlugin 来显示错误信息到控制台
quiet: true,
// webpack 使用文件系统(file system)获取文件改动的通知。监视文件 https://webpack.js.org/configuration/dev-server/#devserver-watchoptions-
watchOptions: {
poll: false,
},
disableHostCheck: true,
},
};
webpack-dev-server 具有许多可配置的选项。关于其他更多配置，请查看配置文档
使用 webpack-dev-middleware
此选项控制是否生成，以及如何生成source map
使用 SourceMapDevToolPlugin 进行更细粒度的配置。查看 source-map-loader 来处理已有的 source map。
devtool
string false
选择一种 source map 格式来增强调试过程。不同的值会明显影响到构建(build)和重新构建(rebuild)的速度。
你可以直接使用 SourceMapDevToolPlugin/EvalSourceMapDevToolPlugin 来替代使用 devtool 选项，因为它有更多的选项。切勿同时使用 devtool 选项和 SourceMapDevToolPlugin/EvalSourceMapDevToolPlugin 插件。devtool 选项在内部添加过这些插件，所以你最终将应用两次插件。
git 仓库 里有用于测试 Source Map 示例，便于理解下面的 Source Map 对比表格
| devtool | 构建速度 | 重新构建速度 | 生产环境 | 质量(quality) |
| — | — | — | — | — |
| none | +++ | +++ | yes | 打包后的代码 |
| eval | +++ | +++ | no | 生成后的代码 |
| cheap-eval-source-map | + | ++ | no | 转换过的代码（仅限行） |
| cheap-module-eval-source-map | o | ++ | no | 原始源代码（仅限行） |
| eval-source-map | – | + | no | 原始源代码 |
| cheap-source-map | + | o | no | 转换过的代码（仅限行） |
| cheap-module-source-map | o | - | no | 原始源代码（仅限行） |
| inline-cheap-source-map | + | o | no | 转换过的代码（仅限行） |
| inline-cheap-module-source-map | o | - | no | 原始源代码（仅限行） |
| source-map | – | – | yes | 原始源代码 |
| inline-source-map | – | – | no | 原始源代码 |
| hidden-source-map | – | – | yes | 原始源代码 |
| nosources-source-map | – | – | yes | 无源代码内容 |
+++ 非常快速, ++ 快速, + 比较快, o 中等, - 比较慢, – 慢
其中一些值适用于开发环境，一些适用于生产环境。对于开发环境，通常希望更快速的 source map，需要添加到 bundle 中以增加体积为代价，但是对于生产环境，则希望更精准的 source map，需要从 bundle 中分离并独立存在。
质量(quality)说明
- 打包后的代码
将所有生成的代码视为一大块代码。你看不到相互分离的模块。
- 生成后的代码
每个模块相互分离，并用模块名称进行注释。可以看到 webpack 生成的代码。示例：你会看到类似 var moduleWEBPACK_IMPORTED_MODULE_1 = webpack_require(42); moduleWEBPACK_IMPORTED_MODULE_1.a();，而不是 import {test} from “module”; test();。
- 转换过的代码
每个模块相互分离，并用模块名称进行注释。可以看到 webpack 转换前、loader 转译后的代码。示例：你会看到类似 import {test} from “module”; var A = function(_test) { … }(test);，而不是 import {test} from “module”; class A extends test {}。
- 原始源代码
每个模块相互分离，并用模块名称进行注释。你会看到转译之前的代码，正如编写它时。这取决于 loader 支持。
- 无源代码内容
source map 中不包含源代码内容。浏览器通常会尝试从 web 服务器或文件系统加载源代码。你必须确保正确设置 output.devtoolModuleFilenameTemplate，以匹配源代码的 url。
- （仅限行）
source map 被简化为每行一个映射。这通常意味着每个语句只有一个映射（假设你使用这种方式）。这会妨碍你在语句级别上调试执行，也会妨碍你在每行的一些列上设置断点。与压缩后的代码组合后，映射关系是不可能实现的，因为压缩工具通常只会输出一行。
对于开发环境
以下选项非常适合开发环境：
- eval
每个模块都使用 eval() 执行，并且都有 //@ sourceURL。此选项会非常快地构建。主要缺点是，由于会映射到转换后的代码，而不是映射到原始代码（没有从 loader 中获取 source map），所以不能正确的显示行数。
- eval-source-map
每个模块使用 eval() 执行，并且 source map 转换为 DataUrl 后添加到 eval() 中。初始化 source map 时比较慢，但是会在重新构建时提供比较快的速度，并且生成实际的文件。行数能够正确映射，因为会映射到原始代码中。它会生成用于开发环境的最佳品质的 source map。
- cheap-eval-source-map
类似 eval-source-map，每个模块使用 eval() 执行。这是 “cheap(阉割版)” 的 source map，因为它没有生成列映射(column mapping)，只是映射行数。它会忽略源自 loader 的 source map，并且仅显示转译后的代码，就像 eval devtool。
- cheap-module-eval-source-map
类似 cheap-eval-source-map，并且，在这种情况下，源自 loader 的 source map 会得到更好的处理结果。然而，loader source map 会被简化为每行一个映射(mapping)。
特定场景
以下选项对于开发环境和生产环境并不理想。他们是一些特定场景下需要的，例如，针对一些第三方工具。
- inline-source-map
source map 转换为 DataUrl 后添加到 bundle 中。
- cheap-source-map
没有列映射(column mapping)的 source map，忽略 loader source map。
- inline-cheap-source-map
类似 cheap-source-map，但是 source map 转换为 DataUrl 后添加到 bundle 中。
- cheap-module-source-map
没有列映射(column mapping)的 source map，将 loader source map 简化为每行一个映射(mapping)。
- inline-cheap-module-source-map
类似 cheap-module-source-map，但是 source map 转换为 DataUrl 添加到 bundle 中。
对于生产环境
这些选项通常用于生产环境中：
- none（省略 devtool 选项）
不生成 source map。这是一个不错的选择。
- source-map
整个 source map 作为一个单独的文件生成。它为 bundle 添加了一个引用注释，以便开发工具知道在哪里可以找到它。
你应该将你的服务器配置为，不允许普通用户访问 source map 文件！
- hidden-source-map
与 source-map 相同，但不会为 bundle 添加引用注释。如果你只想 source map 映射那些源自错误报告的错误堆栈跟踪信息，但不想为浏览器开发工具暴露你的 source map，这个选项会很有用。
你不应将 source map 文件部署到 web 服务器。而是只将其用于错误报告工具。
- nosources-source-map
创建的 source map 不包含 sourcesContent(源代码内容)。它可以用来映射客户端上的堆栈跟踪，而无须暴露所有的源代码。你可以将 source map 文件部署到 web 服务器。
这仍然会暴露反编译后的文件名和结构，但它不会暴露原始代码。
在使用 uglifyjs-webpack-plugin 时，你必须提供 sourceMap：true 选项来启用 source map 支持。
模块热替换(HMR - Hot Module Replacement)功能会在应用程序运行过程中替换、添加或删除模块，而无需重新加载整个页面。主要是通过以下几种方式，来显著加快开发速度：
-
保留在完全重新加载页面时丢失的应用程序状态。
-
只更新变更内容，以节省宝贵的开发时间。
-
调整样式更加快速 - 几乎相当于在浏览器调试器中更改样式。
在应用程序中
通过以下步骤，可以做到在应用程序中置换(swap in and out)模块：
-
应用程序代码要求 HMR runtime 检查更新。
-
HMR runtime（异步）下载更新，然后通知应用程序代码。
-
应用程序代码要求 HMR runtime 应用更新。
-
HMR runtime（同步）应用更新。
你可以设置 HMR，以使此进程自动触发更新，或者你可以选择要求在用户交互时进行更新。
在编译器中
除了普通资源，编译器(compiler)需要发出 “update”，以允许更新之前的版本到新的版本。“update” 由两部分组成：
-
更新后的 manifest(JSON)
-
一个或多个更新后的 chunk (JavaScript)
manifest 包括新的编译 hash 和所有的待更新 chunk 目录。每个更新 chunk 都含有对应于此 chunk 的全部更新模块（或一个 flag 用于表明此模块要被移除）的代码。
编译器确保模块 ID 和 chunk ID 在这些构建之间保持一致。通常将这些 ID 存储在内存中（例如，使用 webpack-dev-server 时），但是也可能将它们存储在一个 JSON 文件中。
在模块中
HMR 是可选功能，只会影响包含 HMR 代码的模块。举个例子，通过 style-loader 为 style 样式追加补丁。为了运行追加补丁，style-loader 实现了 HMR 接口；当它通过 HMR 接收到更新，它会使用新的样式替换旧的样式。
类似的，当在一个模块中实现了 HMR 接口，你可以描述出当模块被更新后发生了什么。然而在多数情况下，不需要强制在每个模块中写入 HMR 代码。如果一个模块没有 HMR 处理函数，更新就会冒泡(bubble up)。这意味着一个简单的处理函数能够对整个模块树(complete module tree)进行更新。如果在这个模块树中，一个单独的模块被更新，那么整组依赖模块都会被重新加载。
有关 module.hot 接口的详细信息，请查看 HMR API 页面。
在 HMR Runtime 中
这些事情比较有技术性……如果你对其内部不感兴趣，可以随时跳到 HMR API 页面或 HMR 用例。
对于模块系统的 runtime，附加的代码被发送到 parents 和 children 跟踪模块。在管理方面，runtime 支持两个方法 check 和 apply。
check 发送 HTTP 请求来更新 manifest。如果请求失败，说明没有可用更新。如果请求成功，待更新 chunk 会和当前加载过的 chunk 进行比较。对每个加载过的 chunk，会下载相对应的待更新 chunk。当所有待更新 chunk 完成下载，就会准备切换到 ready 状态。
apply 方法将所有被更新模块标记为无效。对于每个无效模块，都需要在模块中有一个更新处理函数(update handler)，或者在它的父级模块们中有更新处理函数。否则，无效标记冒泡，并也使父级无效。每个冒泡继续，直到到达应用程序入口起点，或者到达带有更新处理函数的模块（以最先到达为准，冒泡停止）。如果它从入口起点开始冒泡，则此过程失败。
之后，所有无效模块都被（通过 dispose 处理函数）处理和解除加载。然后更新当前 hash，并且调用所有 “accept” 处理函数。runtime 切换回闲置状态(idle state)，一切照常继续。
如果已经通过 HotModuleReplacementPlugin 启用了 HMR，则它的接口将被暴露在 module.hot 属性下面。通常，用户先要检查这个接口是否可访问，然后再开始使用它。举个例子，你可以这样 accept 一个更新的模块：
if (module.hot) {
module.hot.accept(‘./library.js’, function () {
// 使用更新过的 library 模块执行某些操作…
});
}
accept
接受(accept)给定依赖模块的更新，并触发一个回调函数来对这些更新做出响应。
module.hot.accept(
dependencies, // 可以是一个字符串或字符串数组
callback, // 用于在模块更新后触发的函数
);
使用 ESM import 时，将从依赖项中导入的所有符号自动更新。 注意：依赖项字符串必须与 import 中的 from 字符串完全匹配。 在某些情况下，甚至可以省略 callback。 在回调中使用 require()没有意义。
使用 CommonJS 时，您需要通过在 callback 中使用 require()来手动更新依赖项。 省略 callback 在这里没有意义。
decline
拒绝给定依赖模块的更新，使用decline方法强制更新失败。
module.hot.decline(
dependencies, // 可以是一个字符串或字符串数组
);
dispose（或 addDisposeHandler）
添加一个处理函数，在当前模块代码被替换时执行。此函数应该用于移除你声明或创建的任何持久资源。如果要将状态传入到更新过的模块，请添加给定 data 参数。更新后，此对象在更新之后可通过 module.hot.data 调用。
module.hot.dispose((data) => {
// 清理并将 data 传递到更新后的模块……
});
removeDisposeHandler
删除由 dispose 或 addDisposeHandler 添加的回调函数。
module.hot.removeDisposeHandler(callback);
status
取得模块热替换进程的当前状态。
module.hot.status(); // 返回以下字符串之一……
| Status | 描述 |
| — | — |
| idle | 该进程正在等待调用 check（见下文） |
| check | 该进程正在检查以更新 |
| prepare | 该进程正在准备更新（例如，下载已更新的模块） |
| ready | 此更新已准备并可用 |
| dispose | 该进程正在调用将被替换模块的 dispose 处理函数 |
| apply | 该进程正在调用 accept 处理函数，并重新执行自我接受(self-accepted)的模块 |
| abort | 更新已中止，但系统仍处于之前的状态 |
| fail | 更新已抛出异常，系统状态已被破坏 |
check
测试所有加载的模块以进行更新，如果有更新，则应用它们。
module.hot
.check(autoApply)
.then((outdatedModules) => {
// 超时的模块……
})
.catch((error) => {
// 捕获错误
});
autoApply 参数可以是布尔值，也可以是 options，当被调用时可以传递给 apply 方法
可选的 options 对象可以包含以下属性：
| options | 描述 |
| — | — |
| ignoreUnaccepted (boolean) | 忽略对未接受的模块所做的更改。 |
| ignoreDeclined (boolean) | 忽略对拒绝的模块所做的更改。 |
| ignoreErrored (boolean) | 忽略接受处理函数，错误处理函数以及重新评估模块时抛出的错误。 |
| onDeclined (function(info)) | 拒绝模块的通知者 |
| onUnaccepted (function(info)) | 未接受模块的通知程序 |
| onAccepted (function(info)) | 接受模块的通知者 |
| onDisposed (function(info)) | 废弃模块的通知者 |
| onErrored (function(info)) | 异常通知者 |
info 参数可能存在以下对象：
{
type: “self-declined” | “declined” |
“unaccepted” | “accepted” |
“disposed” | “accept-errored” |
“self-accept-errored” | “self-accept-error-handler-errored”,
moduleId: 4, // The module in question.
dependencyId: 3, // For errors: the module id owning the accept handler.
chain: [1, 2, 3, 4], // For declined/accepted/unaccepted: the chain from where the update was propagated.
parentId: 5, // For declined: the module id of the declining parent
outdatedModules: [1, 2, 3, 4], // For accepted: the modules that are outdated and will be disposed
outdatedDependencies: { // For accepted: The location of accept handlers that will handle the update
5: [4]
},
error: new Error(…), // For errors: the thrown error
originalError: new Error(…) // For self-accept-error-handler-errored:
// the error thrown by the module before the error handler tried to handle it.
}
addStatusHandler
注册一个函数来监听 status 的变化。
module.hot.addStatusHandler((status) => {
// 响应当前状态……
});
removeStatusHandler
移除一个注册的状态处理函数。
module.hot.removeStatusHandler(callback);
模块热替换(Hot Module Replacement 或 HMR)是 webpack 提供的最有用的功能之一。它允许在运行时更新各种模块，而无需进行完全刷新。
HMR 不适用于生产环境，这意味着它应当只在开发环境使用
启用 HMR
配置 webpack-dev-server ，并使用 webpack 的内置 HMR 插件
HMR 修改样式
借助于 style-loader 的帮助，CSS 的模块热替换实际上是相当简单的。当更新 CSS 依赖模块时，此 loader 在后台使用 module.hot.accept 来修补(patch)
所以，可以使用以下命令安装两个 loader ：
npm i style-loader css-loader -D
接下来我们来更新 webpack 的配置，让这两个 loader 生效。
webpack.config.js
const path = require(‘path’);
const HtmlWebpackPlugin = require(‘html-webpack-plugin’);
const { CleanWebpackPlugin } = require(‘clean-webpack-plugin’);
const webpack = require(‘webpack’);
module.exports = {
mode: ‘development’,
entry: {
main: ‘./src/main.js’,
},
output: {
path: path.join(__dirname, ‘dist’),
filename: ‘main.js’,
},
devtool: ‘eval-source-map’,
devServer: {
contentBase: false,
hot: true,
open: true,
},
plugins: [new CleanWebpackPlugin(), new HtmlWebpackPlugin()],
module: {
rules: [
{
test: /.css$/,
use: [
{
loader: ‘style-loader’,
},
{
loader: ‘css-loader’,
},
],
},
],
},
};
src/textarea.js
module.exports = function () {
const textarea = document.createElement(‘textarea’);
textarea.id = ‘text’;
return textarea;
};
src/assets/main.css
#text {
color: red;
}
src/main.js
import ‘./assets/main.css’;
import textarea from ‘./textarea’;
const textareaEl = textarea();
const body = document.body;
body.appendChild(textareaEl);
将 id 为 text 上的样式修改为 color: black，你可以立即看到页面的字体颜色随之更改，但并未刷新页面。
src/assets/main.css
#text {
color: black;
}
HMR 修改 js
这里我们使用HMR API里的accept来修补(patch)
webpack.config.js 配置
const path = require(‘path’);
const HtmlWebpackPlugin = require(‘html-webpack-plugin’);
const { CleanWebpackPlugin } = require(‘clean-webpack-plugin’);
const webpack = require(‘webpack’);
module.exports = {
mode: ‘development’,
entry: {
main: ‘./src/main.js’,
},
output: {
path: path.join(__dirname, ‘dist’),
filename: ‘main.js’,
},
devtool: ‘eval-source-map’,
devServer: {
contentBase: false,
hot: true,
open: true,
},
optimization: {
NamedModulesPlugin,
},
plugins: [
new CleanWebpackPlugin(),
new HtmlWebpackPlugin(),
new webpack.HotModuleReplacementPlugin(),
],
};
我们还添加了 NamedModulesPlugin，以便更容易查看要修补(patch)的依赖.
src/textarea.js
module.exports = function () {
const textarea = document.createElement(‘textarea’);
textarea.id = ‘text’;
return textarea;
};
src/main.js
import textarea from ‘./textarea’;
let textareaEl = textarea();
const body = document.body;
body.appendChild(textareaEl);
// 判断是否开启模块热替换
if (module.hot) {
module.hot.accept(‘./textarea.js’, () => {
console.log(‘Accepting the updated textarea module!’);
// 获取页面重新渲染前的值
const val = textareaEl.value;
// 移除Element
body.removeChild(textareaEl);
// 这里拿到的是最新的Element
textareaEl = textarea();
// 将value值写入
textareaEl.value = val;
// 添加Element
body.appendChild(textareaEl);
});
}
将 id 修改为 text1，你可以立即看到页面的 textarea 标签 id 也随之更改，但并未刷新页面。
src/textarea.js
module.exports = function () {
const textarea = document.createElement(‘textarea’);
textarea.id = ‘text1’;
return textarea;
};
开发环境(development)和生产环境(production)的构建目标差异很大。在开发环境中，我们需要具有强大的、具有实时重新加载(live reloading)或热模块替换(hot module replacement)能力的 source map 和 localhost server。而在生产环境中，我们的目标则转向于关注更小的 bundle，更轻量的 source map，以及更优化的资源，以改善加载时间。建议为每个环境编写彼此独立的 webpack 配置。
因为生产环境和开发环境的配置只有略微区别，所以将共用部分的配置作为一个通用配置。使用webpack-merge工具，将这些配置合并在一起。通过通用配置，我们不必在不同环境的配置中重复代码。
安装webpack-merge
npm i webpack-merge -D
示例
build/webpack.base.config.js
const path = require(‘path’);
const HtmlWebpackPlugin = require(‘html-webpack-plugin’);
const { CleanWebpackPlugin } = require(‘clean-webpack-plugin’);
module.exports = {
entry: {
main: ‘./src/main.js’,
},
output: {
path: path.join(__dirname, ‘…/dist’),
filename: ‘main.js’,
},
plugins: [new CleanWebpackPlugin(), new HtmlWebpackPlugin()],
module: {
rules: [
{
test: /.css$/,
use: [
{
loader: ‘style-loader’,
},
{
loader: ‘css-loader’,
},
],
},
{
test: /.txt$/,
use: {
loader: ‘raw-loader’,
},
},
{
test: require.resolve(‘…/src/answer.js’),
use: {
loader: ‘val-loader’,
},
},
{
test: /.(png|jpge|jpg|git|svg)$/,
use: {
loader: ‘file-loader’,
options: {},
},
},
],
},
};
webpack.dev.config.js
const webpack = require(‘webpack’);
const { merge } = require(‘webpack-merge’);
const baseConfig = require(‘./webpack.base.config’);
module.exports = merge(baseConfig, {
mode: ‘development’,
devtool: ‘eval-source-map’,
devServer: {
contentBase: false,
hot: true,
open: true,
},
plugins: [
new webpack.NamedModulesPlugin(),
new webpack.HotModuleReplacementPlugin(),
],
});
webpack.pro.config.js
const path = require(‘path’);
const UglifyJSPlugin = require(‘uglifyjs-webpack-plugin’);
const merge = require(‘webpack-merge’);
const baseConfig = require(‘./webpack.base.config’);
module.exports = merge(baseConfig, {
mode: ‘production’,
devtool: false,
plugins: [new UglifyJSPlugin()],
});
Tree Shaking 是一个术语，通常用于描述移除 JavaScript 上下文中的未引用代码(dead-code)。它依赖于 ES2015 模块系统中的静态结构特性，例如 import 和 export。这个术语和概念实际上是兴起于 ES2015 模块打包工具 rollup。
你可以将未引用代码(dead-code)理解为枯树叶，使用 Tree Shaking 「摇掉」枯树叶
webpack 的 mode 为 production 时，会自动开启 Tree Shaking
optimization.usedExports
boolean = true
负责标记「枯树叶」
代码分离是 webpack 中最引人注目的特性之一。此特性能够把代码分离到不同的 bundle 中，然后可以按需加载或并行加载这些文件。代码分离可以用于获取更小的 bundle，以及控制资源加载优先级，如果使用合理，会极大影响加载时间。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）
最后：
总结来说，面试成功=基础知识+项目经验+表达技巧+运气。我们无法控制运气，但是我们可以在别的地方花更多时间，每个环节都提前做好准备。
面试一方面是为了找到工作，升职加薪，另一方面也是对于自我能力的考察。能够面试成功不仅仅是来自面试前的临时抱佛脚，更重要的是在平时学习和工作中不断积累和坚持，把每个知识点、每一次项目开发、每次遇到的难点知识，做好积累，实践和总结。
merge(baseConfig, {
mode: ‘production’,
devtool: false,
plugins: [new UglifyJSPlugin()],
});
Tree Shaking 是一个术语，通常用于描述移除 JavaScript 上下文中的未引用代码(dead-code)。它依赖于 ES2015 模块系统中的静态结构特性，例如 import 和 export。这个术语和概念实际上是兴起于 ES2015 模块打包工具 rollup。
你可以将未引用代码(dead-code)理解为枯树叶，使用 Tree Shaking 「摇掉」枯树叶
webpack 的 mode 为 production 时，会自动开启 Tree Shaking
optimization.usedExports
boolean = true
负责标记「枯树叶」
代码分离是 webpack 中最引人注目的特性之一。此特性能够把代码分离到不同的 bundle 中，然后可以按需加载或并行加载这些文件。代码分离可以用于获取更小的 bundle，以及控制资源加载优先级，如果使用合理，会极大影响加载时间。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-AkQYESji-1713781617573)]
[外链图片转存中…(img-uiYtxLTr-1713781617573)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
[外链图片转存中…(img-jJlva9cX-1713781617573)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）
[外链图片转存中…(img-QXVtAtV9-1713781617574)]
最后：
总结来说，面试成功=基础知识+项目经验+表达技巧+运气。我们无法控制运气，但是我们可以在别的地方花更多时间，每个环节都提前做好准备。
面试一方面是为了找到工作，升职加薪，另一方面也是对于自我能力的考察。能够面试成功不仅仅是来自面试前的临时抱佛脚，更重要的是在平时学习和工作中不断积累和坚持，把每个知识点、每一次项目开发、每次遇到的难点知识，做好积累，实践和总结。
1145
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
