π¦The location of the error in the source code is clearly the second line of code, and the error prompted in the browser is indeed on the first line, so if the code is very complicated, we cannot find the specific location of the error
There are 6 common configurations of devtool:
1) source-map: This mode will generate a .map file. If an error occurs, it will prompt specific rows and columns. The file retains the mapping relationship between the packaged file and the original file. The packaged output file will point to the generation The .map file tells the js engine where the source code is. Because the source code is separate from the .map file, it needs a browser to send a request to get the .map file. It is often used in production environments, such as:
/# sourceMappingURL=index.js.map
2) eval: This mode has the fastest packaging speed and does not generate .map files. It will use eval to wrap the module and add sourceURL at the end. It is often used in development environments, such as:
//# sourceURL=webpack:///./src/index.js
3) eval-source-map: Each module will be executed by eval () and generate a SourceMap in the form of DataUrl (that is, the base64 encoding form is embedded at the end of the eval statement), but the .map file will not be generated, which can reduce the network Request *, but the package file will be very large *.
//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8vLi9zcmMvaW5kZXguanM/YjYzNSJdLCJuYW1lcyI6WyJmb28iLCJjb25zb2xlIiwibGciXSwibWFwcGluZ3MiOiJBQUFBLElBQUlBLEdBQUcsR0FBRyxDQUFWO0FBQ0FDLE9BQU8sQ0FBQ0MsRUFBUix1RSxDQUFxQyIsImZpbGUiOiIuL3NyYy9pbmRleC5qcy5qcyIsInNvdXJjZXNDb250ZW50IjpbImxldCBmb28gPSAxO1xuY29uc29sZS5sZyhgY29uc29sZeWvueixoeeahOaWueazleWQjWxvZ+WGmeaIkOS6hmxnYCk7IC8vIOa6kOaWh+S7tuesrOS6jOihjOWHuumUmVxuIl0sInNvdXJjZVJvb3QiOiIifQ==
//# sourceURL=webpack-internal:///./src/index.js
4) cheap-source-map: With cheap, you will only be prompted to the first few lines of error, less column information prompts, and will not map the imported library, which can improve packaging performance, but will generate .map files.
5) Cheap-module-source-map: Compared with cheap-source-map, if you add a module, it will map the imported library, and it will also generate a .map file, which is used in the production environment.
6) cheap-module-eval-source-map: commonly used in development environments, using cheap mode can greatly improve the efficiency of souremap generation, plus module will also map the imported libraries, eval improves the speed of packaging and construction, and will not produce The .map file reduces network requests.
> Any mode with eval cannot be used in a production environment, because it does not generate a .map file, which will cause the packaged file to become very large. Usually we don't care about the column information, so we will use cheap mode, but we still need to map third-party libraries in order to find the wrong location accurately.
@UndercodeTesting
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
There are 6 common configurations of devtool:
1) source-map: This mode will generate a .map file. If an error occurs, it will prompt specific rows and columns. The file retains the mapping relationship between the packaged file and the original file. The packaged output file will point to the generation The .map file tells the js engine where the source code is. Because the source code is separate from the .map file, it needs a browser to send a request to get the .map file. It is often used in production environments, such as:
/# sourceMappingURL=index.js.map
2) eval: This mode has the fastest packaging speed and does not generate .map files. It will use eval to wrap the module and add sourceURL at the end. It is often used in development environments, such as:
//# sourceURL=webpack:///./src/index.js
3) eval-source-map: Each module will be executed by eval () and generate a SourceMap in the form of DataUrl (that is, the base64 encoding form is embedded at the end of the eval statement), but the .map file will not be generated, which can reduce the network Request *, but the package file will be very large *.
//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8vLi9zcmMvaW5kZXguanM/YjYzNSJdLCJuYW1lcyI6WyJmb28iLCJjb25zb2xlIiwibGciXSwibWFwcGluZ3MiOiJBQUFBLElBQUlBLEdBQUcsR0FBRyxDQUFWO0FBQ0FDLE9BQU8sQ0FBQ0MsRUFBUix1RSxDQUFxQyIsImZpbGUiOiIuL3NyYy9pbmRleC5qcy5qcyIsInNvdXJjZXNDb250ZW50IjpbImxldCBmb28gPSAxO1xuY29uc29sZS5sZyhgY29uc29sZeWvueixoeeahOaWueazleWQjWxvZ+WGmeaIkOS6hmxnYCk7IC8vIOa6kOaWh+S7tuesrOS6jOihjOWHuumUmVxuIl0sInNvdXJjZVJvb3QiOiIifQ==
//# sourceURL=webpack-internal:///./src/index.js
4) cheap-source-map: With cheap, you will only be prompted to the first few lines of error, less column information prompts, and will not map the imported library, which can improve packaging performance, but will generate .map files.
5) Cheap-module-source-map: Compared with cheap-source-map, if you add a module, it will map the imported library, and it will also generate a .map file, which is used in the production environment.
6) cheap-module-eval-source-map: commonly used in development environments, using cheap mode can greatly improve the efficiency of souremap generation, plus module will also map the imported libraries, eval improves the speed of packaging and construction, and will not produce The .map file reduces network requests.
> Any mode with eval cannot be used in a production environment, because it does not generate a .map file, which will cause the packaged file to become very large. Usually we don't care about the column information, so we will use cheap mode, but we still need to map third-party libraries in order to find the wrong location accurately.
@UndercodeTesting
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦Three, watch and watchOptions configuration :
Webpack can monitor file changes, and recompile when they are modified. If you need to enable this function, you need to set watch to true, and the specific monitoring configuration can be set through watchOptions.
Webpack can monitor file changes, and recompile when they are modified. If you need to enable this function, you need to set watch to true, and the specific monitoring configuration can be set through watchOptions.
Four, the use of three common widgets
> clean-webpack-plugin: Its function is to clear the contents of the output directory before packing, and then output the packaged output files to the output directory.
> clean-webpack-plugin: Its function is to clear the contents of the output directory before packing, and then output the packaged output files to the output directory.
π¦It should be noted that the result of require ("clean-webpack-plugin) is an object instead of a class. The CleanWebpackPlugin attribute in this object is a class. We use this class to create plug-in objects.
2. copy-webpack-plugin: Its role is to bring some readMe.md, history.md, etc. into the output directory when packing.
2. copy-webpack-plugin: Its role is to bring some readMe.md, history.md, etc. into the output directory when packing.
3) BannerPlugin: Its role is to add some text comments at the head of the packaged js file, such as copyright notes, etc. BannerPlugin is a built-in plugin for webpack, such as:
Five, webpack cross-domain issues
a) Why does webpack have cross-domain issues? Because webpack packages the front-end code, it will eventually be deployed to the front-end server, and the front-end and back-end code are usually deployed on different servers. Even if they are deployed on the same server, the ports used are different.
> When the code obtains data from the back-end server through means such as ajax, there is a cross-domain problem because the front-end and back-end codes are not in the same domain.
> For example, we use webpack's devServer to run and deploy our front-end application code. DevServer starts on port 8080, while the front-end application code requests back-end data through ajax, and the back-end server starts on port 3000.
a) Why does webpack have cross-domain issues? Because webpack packages the front-end code, it will eventually be deployed to the front-end server, and the front-end and back-end code are usually deployed on different servers. Even if they are deployed on the same server, the ports used are different.
> When the code obtains data from the back-end server through means such as ajax, there is a cross-domain problem because the front-end and back-end codes are not in the same domain.
> For example, we use webpack's devServer to run and deploy our front-end application code. DevServer starts on port 8080, while the front-end application code requests back-end data through ajax, and the back-end server starts on port 3000.
π¦Because the front-end code runs in the browser, if the front-end code directly initiates a request to http: // localhost: 3000 / api / test to obtain data through ajax, then due to the influence of the browser's same-origin policy, there will be cross-domain Problem, so you must visit / api / test.
> However, this access will cause 404 problems, because in fact, access is http: // localhost: 8080 / api / test, 8080 server does not have the resource, the solution is to configure a proxy server through devServer
> However, this access will cause 404 problems, because in fact, access is http: // localhost: 8080 / api / test, 8080 server does not have the resource, the solution is to configure a proxy server through devServer
π¦Visit http: // localhost: 8080 / api / test
It will be proxied to http: // localhost: 3000 / api / test, proxy also supports path rewriting, if there is no / api / test path on the 3000 port server, only / test path, then you can perform the path Rewrite, replace / api
It will be proxied to http: // localhost: 3000 / api / test, proxy also supports path rewriting, if there is no / api / test path on the 3000 port server, only / test path, then you can perform the path Rewrite, replace / api
π¦Visit http: // localhost: 8080 / api / test
Will be proxied to http: // localhost: 3000 / test
If the front end just wants to mock some data and does not need to actually access the backend server, then we can obtain the built-in server object through the before hook function provided by devServer to process the request. This built-in server object is webpack's devServer, which is port 8080 The server, because it is requesting data in the same server, there will be no cross-domain problems.
Will be proxied to http: // localhost: 3000 / test
If the front end just wants to mock some data and does not need to actually access the backend server, then we can obtain the built-in server object through the before hook function provided by devServer to process the request. This built-in server object is webpack's devServer, which is port 8080 The server, because it is requesting data in the same server, there will be no cross-domain problems.
We can also start webpack without the devServer provided by webpack, but use our own server to start webapck.