34:["$","title",null,{"children":"Introduction to packing and building applications with Webpack 4 | Ante Tomić | Observable"}] 3c:T4a9,dot`digraph { 1[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri, shape=house, fontsize=24]; 2[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 3[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 4[label=".CSS", color=dodgerblue, fontcolor=dodgerblue3, fontname=Calibri]; 5[label=".CSS", color=dodgerblue, fontcolor=dodgerblue3, fontname=Calibri]; 6[label=".CSS", color=dodgerblue, fontcolor=dodgerblue3, fontname=Calibri]; 7[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 8[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 9[label=".PNG", color=brown2, fontcolor=brown4, fontname=Calibri]; 10[label=".JPG", color=brown2, fontcolor=brown4, fontname=Calibri]; 11[label=".SVG", color=brown2, fontcolor=brown4, fontname=Calibri]; 12[label=".PNG", color=brown2, fontcolor=brown4, fontname=Calibri]; 1 -> 2 [color=darkorange] 1 -> 3 [color=darkorange] 1 -> 4 [color=dodgerblue] 4 -> 5 [color=dodgerblue] 4 -> 6 [color=dodgerblue] 2 -> 7 [color=darkorange] 3 -> 8 [color=darkorange] 8 -> 9 [color=brown2] 5 -> 10 [color=brown2] 6 -> 11 [color=brown2] 11 -> 12 [color=brown2] } `3d:T421,md`## Installing the dependencies To start with Webpack, we need to install the necessary dependencies. There are 2 dependencies tha are necessary for Webpack 4.x: _webpack_ and _webpack-cli_. Why 2 separate dependencies? The _webpack_ dependency includes everything necessary for Webpack configuration, while _webpack-cli_ includes all CLI commands for running Webpack easier. Here we will simply use NPM to install those dependencies: \`\`\` npm i webpack webpack-cli -D \`\`\` We are using the standard NPM install function (_npm install_ or shorter _npm i_) which will install specified dependencies and everything dependencies need for running. Additionally, since this is dependency necessary only for building the application, not running it, I am putting it in devDependencies by specifying the __-D__ flag or longer __--save-dev__. For production (aka code necessary for runtime), use __-P__ flag or longer __--save__. This will add the latest versions of those 2 dependencies and all necessary dependencies in package.json and node_modules.`3e:T512,md`## Writing everything else So, what else is necessary to run a Webpack build? Assuming that we already have a sample _JavaScript_ file, nothing! Yeah that's right, Webpack supports building the application without any configuration. __So, presentation is over, let's go home early!__ Jk ${html`😜😜`} Let's look at the example for this. We will create a folder called _src_ where we will put a JavaScript code (I will create _index.js_ for the purpose the following code: \`\`\`javascript console.log("Hello world from .NET Meetup!"); \`\`\` We will start simple for the start ${html`😄`}. To make things easier, we will head to _package.json_ where we will add the following part of the code inside the JSON object: \`\`\` "scripts": { "build": "webpack" } \`\`\` We will come back to scripts to explain everything later, let's now just stick to trying Webpack with 0 configuration code ${html`😄`}. Then we will head to the console and write the following command to check out beautiful output: \`\`\` npm run build \`\`\` As you can see, Webpack saves the output inside of _dist_ folder and with this we got the first JavaScript file which is an output bundle! `3f:T4ac,md`At the beginning, we need to install _html-webpack-plugin_: \`\`\` npm i html-webpack-plugin -D \`\`\` If we need multiple HTML features, we can use _html-webpack-plugin_, but if you need something simpler, something that doesn't require a lot, you can use _mini-html-webpack-plugin_ which is more lightweight version of HTML plugin with only basic features. The next step is to create __webpack.config.js__ in root location of your project (wherever _package.json_ is). We need to do this because Webpack looks for configuration by default on that location. After we have created webpack.config.js, we can start with creating our configuration: \`\`\`javascript const HtmlWebpackPlugin = require("html-webpack-plugin"); module.exports = { plugins: [ new HtmlWebpackPlugin({ title: "Webpack .NET meetup", }), ], }; \`\`\` Since this is a plugin, we need to put it inside of _plugins_ property where we will only specify a HTML title for now. After that, all we need to do is run _npm run build_ in console and that's it, we have JS and HTML files so far! We can open it to see the result and we can notice that we now have an _index.html_ file together with JavaScript bundle. `40:T457,md`Currently we are doing this: we always write code, save the files (or multiple files), run Webpack configuration to get output and then open the file or click F5 in browser if our file is already opened. This seems like a bit too much manual work and something like _Wash, Rinse, Repeat_, doesn't it? ${html`😜`} How can we avoid this? We need to add something! So, basically what we want to get is this: * better development * automatic reloading of files after change * serving files on some location One of the possible solutions is _webpack --watch_ which updates the files which were changed, but it doesn't offer anything else. So, what else could we use? Maaaybe some kind of development server? We have __webpack-dev-server__ which supports everything we need. That sounds like something we can use, so let's try it out! Additionally, it also supports _Hot Module Replacement_ which allows you to update the application without forcing a new refresh. You can check out more about it in Webpack documentation, but it is really _cool_ and _useful_ feature. :)`41:T4b4,md`We have JavaScript, HTML and development server, so what's next? Let's look at one example. Before we do that, let's update package.json. We need to go to __package.json__ and update _scripts_ section inside already existing JSON object (just replace scripts with this): \`\`\` "scripts": { "start": „webpack-dev-server –mode development”, "build:dev": „webpack –mode development”, "build": „webpack –mode production” } \`\`\` We see that everything works in our browser, but let's check the output, is there everything ok? No, it's not! We can see that Webpack generated output that contains _const_ and that may not work well with older browsers. There is one good website called __Can I Use...__ that can help us with checking this, so let's see what it says for _const_: [LINK](https://caniuse.com/#search=const). If we or anyone else use anything that is _not_ green, we are in trouble because it's either not supported or partially supported, so we need to convert this to something browsers can read. We can do that by using __Babel__ which is the JavaScript code compiler that allows you to write new syntax which is then converted to something browsers can read. `42:T568,md`What does each part here do? As you can see, _rules_ is an array or objects and each object contains definition for specific rule. Here we are defining that Webpack should use this rule for JavaScript files. We do that by defining regex pattern in _test_. To optimize application build, it is recommended to set _include/exclude_ where you tell Webpack which files groups it should read (e.g. all files in folderA/subfolderB) or which files it should skip. You need to pass a path one level up (if you wanna exclude _client/src/components/a.css_, pass _client/src/components/_. The _use_ property defines loaders for using with necessary files. It can be either a simple string (if we need only one loader), an array of strings (if we need loaders without any optimizations) or an array of objects (loaders with modifications). We will use the last one. The obvious property is loader where we define the desired loader. :) All options related to loader go under _options_ property which is different for every loader. Here, because we want to use latest JavaScript syntax, we need to tell Babel to use _@babel/preset-env_. We do that by defining presets. After we have defined this, we can try to run the Webpack configuration with newer syntax and everything will work properly! We can see that we have now received _var_ instead of _const_, so we know that Babel is working!`43:T799,md`By definition, polyfills represent the code that implements something that Web browsers don't support yet. That will mostly be the case with older versions of browsers ... and _Internet Explorer_. For example, let's use __Can I Use__ to check array functions: [LINK](https://caniuse.com/#search=array). If we show browsers with min. 0.3% usage, we see that all browsers except IE11 implement e.g. _array.find()_. So, how to solve this? One option is fairly simple: __polyfill.io__. You can go to this URL ([CLICK](https://polyfill.io/v3/url-builder)), choose which polyfills you want to use, copy the generated URL and include it in HTML. If your browser doesn't support some feature, polyfill will be added. But this way you can include polyfills for features you _don't use_ and that can make page loading slower. Is there any more effective solution? Yeah there is! We can use already installed Babel and _@babel/preset-env_! Before we start, we need to install one NPM package: \`\`\` npm i core-js -D \`\`\` The _core-js_ NPM package contains a set of polyfill functions that can be manually included or by using _@babel/preset-env_ what we will do. So, what does _@babel/preset-env_ do here? It can check your code and include only polyfills that are necessary (unsupported syntax or functions used in code). Let's check how to use it: \`\`\`javascript module: { rules: [{ test: /\\.(js|jsx)?$/, exclude: [nodeModules], // Let's simplify, imagine that we defined a constant somewhere use: [{ // 'babel-loader' enough if we are not using any options loader: 'babel-loader', options: { presets: [ ['@babel/preset-env', { // Instead of '@babel/preset-env' targets: { browsers: ['>= 0.25%', 'IE 11', 'since 2017', 'not op_mini all'] }, useBuiltIns: 'usage' }] ] } }] }] } \`\`\` `44:T7e6,md`We are defining the usual stuff: _test_ where we define regex to check only specific file extensions, _include/exclude_ which are recommended to be set up in this case to optimize build time and loaders. The only thing that is specific here is that we are using _url-loader_ which, when combined with _file-loader_, opens many possibilities. When we are using _url-loader_ there are 2 settings that are recommended for setting up: __name__ where you have many possibilities (check placeholders here: [CLICK](https://www.npmjs.com/package/file-loader#placeholders)) and __limit__ which basically says: when filesize is lower than N bytes, use url-loader, otherwise use _fallback loader_. We don't need to define the fallback loader because it is defined as _file-loader_ by default and that's why we need both. If we want to, we can use _file-loader_ directly and in that case we don't need _url-loader_ dependency. Now let's try to add new folder called _assets_ inside of _src_ where we will add the picture! Also, for simplicity, we will assume all of our pictures will be in _CSS_. That's why we defined _publicPath_ which basically means how will CSS access pictures (or path to pictures' location). Now the only thing left to do is adding the image to CSS and making it visible via JS. First we add the following after html element rule in CSS file: \`\`\`css // ... .image { background-image: url('../assets/vw_t-roc.jpg'); background-repeat: no-repeat; background-position: center; width: 600px; height: 400px; } \`\`\` And then we add the following to JavaScript file: \`\`\`javascript // ... const image = document.createElement('div'); image.className = 'image'; document.body.appendChild(image); \`\`\` Now let's try to run our Webpack configuration and see the result! As we can see, everything works and now we have covered everything we need for common Web application build. We have JS, HTML, CSS, files and development server! Let's look at a few useful additional features. :)`45:T460,dot`digraph { 1[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 2[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 3[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 4[label=".JS", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 5[label="react", color=deepskyblue2, fontcolor=deepskyblue4, fontname=Calibri, shape=doubleoctagon]; 6[label="react-dom", color=firebrick2, fontcolor=firebrick4, fontname=Calibri, shape=doubleoctagon]; 7[label="react", color=deepskyblue2, fontcolor=deepskyblue4, fontname=Calibri, shape=doubleoctagon]; 8[label="react-dom", color=firebrick2, fontcolor=firebrick4, fontname=Calibri, shape=doubleoctagon]; 9[label="moment", color=azure3, fontcolor=azure4, fontname=Calibri]; 10[label="mobx", color=azure3, fontcolor=azure4, fontname=Calibri]; 11[label="react-select", color=azure3, fontcolor=azure4, fontname=Calibri]; 1 -> 3 [color=darkorange] 2 -> 4 [color=darkorange] 3 -> 5 [color=deepskyblue2] 3 -> 6 [color=firebrick2] 2 -> 7 [color=deepskyblue2] 2 -> 8 [color=firebrick2] 1 -> 9 4 -> 10 4 -> 11 } `46:T4a7,md`The other possible solution is controlling what is separated into new _vendors_ bundle. This is different from the solution above because it specifically says to Webpack what to split. It also satisfies the second point which eliminates the unnecessary downloads when none of _node modules_ bundles is changed. Let's look at how we can add it (instead of automatic splitting): \`\`\`javascript // ... optimization: { splitChunks: { chunks: 'initial', cacheGroups: { default: false, vendors: { test: /node_modules/, name: "vendors", }, }, }, } // ... \`\`\` Instead of directly defining initial chunks, here we define cache groups which represent something similar to entry points. Different cache groups can generate new files. Under it everything is similar to what we are doing for loaders: first we define under _test_ which files we want to separate, then we define the name of our chunk under _name_ and, similar to automatic splitting, under _chunks_ we define which chunks should be chosen for optimization with the same option. `47:T423,dot`digraph { 1[label="app", color=deepskyblue2, fontcolor=deepskyblue4, fontname=Calibri]; 2[label=" ", color=deepskyblue2, fontcolor=deepskyblue4, fontname=Calibri]; 3[label=" ", color=deepskyblue2, fontcolor=deepskyblue4, fontname=Calibri]; 4[label=" ", color=deepskyblue2, fontcolor=deepskyblue4, fontname=Calibri]; 5[label=" ", color=deepskyblue2, fontcolor=deepskyblue4, fontname=Calibri]; 6[label="vendor", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 7[label=" ", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 8[label=" ", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 9[label=" ", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 10[label=" ", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 11[label=" ", color=azure3, fontcolor=azure4, fontname=Calibri]; 12[label=" ", color=azure3, fontcolor=azure4, fontname=Calibri]; 13[label=" ", color=azure3, fontcolor=azure4, fontname=Calibri]; 1 -> 2 2 -> 3 2 -> 4 3 -> 5 6 -> 7 7 -> 8 8 -> 9 7 -> 10 1 -> 7 6 -> 11 11 -> 12 11 -> 13 } `48:T639,md`Parcel is another module bundler which recently started to rise in popularity. It is an alternative to Webpack, so let's quickly compare them. * Configuration * Since version 4.x, Webpack allows configuration out of the box to some extent * Parcel can be completely ran without any configuration * Entry points * Out of the box, Webpack supports only JavaScript files and it requires loaders/plugins to be installed and configured * Parcel can take the HTML file, read it and figure out what is necessary * Transformations * Webpack supports very powerful transformations that can be configured pretty impressively, but it is very limited in what it can do without any configuration * Parcel can automatically detect everything necessary as already pointed out * Tree Shaking * Webpack supports it for quite a while :) * Parcel just recently started to support Tree Shaking * Dev Server * Webpack supports it with _webpack-dev-server_ which has to be installed separately * Parcel has built-in dev server * Hot Module Replacement & Code Splitting * Both Webpack and Parcel support it If they are so similar, how do we decide which one to use? If you need something simpler, quicker, what doesn't require much time to set up and what eliminates worrying about configuring everything, you can use _Parcel_. But if you like having more customization, want to have everything configured down to the last detail and you have possibly complex cases, _Webpack_ is probably the better choice for you. You have to think about what you need to do and then decide what to use.`49:[] 38:{"id":"16db81cf98d0b003","slug":"introduction-to-packing-and-building-applications-with-we","title":"Introduction to packing and building applications with Webpack 4","thumbnail":"34d780565e4cfedacf61b1563bc283f6e2a67ec5d02e000bfe62404a3bf33bc0","access_level":"public","create_time":"$D2019-01-28T20:28:43.257Z","update_time":"$D2019-02-26T05:38:43.431Z","view_time":null,"first_public_time":"$D2019-02-05T15:38:17.305Z","has_unpublished_edits":null,"fork":false,"stars":8,"starred":false,"owner":{"type":"team","id":"fd1b77499a80fc6b","login":"antetmc2","name":"Ante Tomić","avatar_url":"https://avatars-next.observableusercontent.com/66378916fe5953d2e78e36623068fb1075bc462dac5db85522df3f106ba545a0","tier":"starter_2024","bio":"","followed_by_you":false,"follows_you":false},"version":700,"publish_version":700,"role":null,"authored":false,"authors":[{"type":"individual","id":"e11770739ce6ad0f","login":"antetmc2","name":"Ante Tomić","avatar_url":"https://avatars-next.observableusercontent.com/66378916fe5953d2e78e36623068fb1075bc462dac5db85522df3f106ba545a0","tier":null,"bio":"","followed_by_you":false,"follows_you":false}],"members":[{"type":"individual","id":"e11770739ce6ad0f","login":"antetmc2","name":"Ante Tomić","avatar_url":"https://avatars-next.observableusercontent.com/66378916fe5953d2e78e36623068fb1075bc462dac5db85522df3f106ba545a0","tier":null,"role":"editor"}],"comments":[],"custom_thumbnail":false,"trashed":false,"lapsed":null,"subscribed":null,"forks":6,"collection":null,"type":"notebook","body":{"titling":"auto","title":"Introduction to packing and building applications with Webpack 4","cells":[{"id":0,"value":"md`# Introduction to packing and building applications with Webpack 4\n\n## Description (the only part that is in Croatian :D):\n\nKoliko vam se često događalo da prilikom buildanja aplikacija morate paziti da su svi dependencyji uključeni ili „da uključimo tu skriptu prije našeg koda jer inače aplikacija neće raditi“? Koliko je vas koristilo ili čulo za Webpack i želi više naučiti? Ovdje ćemo pogledati kako pomoću Webpacka podesiti buildanje web-aplikacije tako da dobijemo kod koji sadrži sve što je potrebno za učitavanje aplikacije. Ići ćemo od osnovnijih pa do najčešćih naprednijih koncepata. Također ćemo usporediti Webpack s drugim _module bundlerima_ kao Parcel i s _task runnerima_ kao što su Gulp ili Grunt.\n\nP.S. This is in English. :) Also, this is a bit more detailed than the presentation, so feel free to check this if you are curious.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":659,"value":"topic_head('Info')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":661,"value":"md`Slides: [https://github.com/antetmc2/webpack-meetup-slides](https://github.com/antetmc2/webpack-meetup-presentation)\n\nCode from presentation: [https://github.com/antetmc2/webpack-meetup-presentation](https://github.com/antetmc2/webpack-meetup-presentation)\n\nExamples from here are available in code example, while the presentation is pretty basic: just containing some basic parts to explain things a bit easier.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":7,"value":"topic_head('The History of Web')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":16,"value":"build_step('How did everything start?')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":10,"value":"md`We certainly came a long way from where we began with Web. Today there are a lot of websites available, but none of that existed in early 90s. Everything began when Tim Berners-Lee created a first website ever that was dedicated to information on the World Wide Web project. You can check it out on the following link: [CLICK HERE](http://info.cern.ch/hypertext/WWW/TheProject.html). \n\nFrom there things started to evolve and everything started to be more and more advanced. First JavaScript appeared in 1995 which is basically a foundation for everything today. Without JavaScript we wouldn't have React, Webpack, Vue.JS or many more very popular packages and frameworks. Then CSS appeared in 1996 with first full support in March 2000 when Internet Explorer 5.0 for the Macintosh was released.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":27,"value":"build_step('The State of Web Today')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":29,"value":"md`Today, frontend is advancing a lot each day and changes around us are quicker and quicker, so it is very important to be up-to-date with everything what is going on. Thanks to everything advancing pretty quickly, we got a lot of invention of new things and new features. Webpack is very big part of all of that and in this presentation we will focus on that. There are also several issues we have to keep an eye on such as a lot of created output files, having to worry about the order of scripts/stylesheets in HTML, optimization of files and many more. Let's look into Webpack to see how to solve this!`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":31,"value":"topic_head('What is Webpack?')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":185,"value":"$3c","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":33,"value":"md`Webpack is a module bundler what means that it _prepares_ all the files that are necessary for opening a website with user worrying about that as little as possible. It takes the entry files (main files where our code starts) and it checks them to see what does it need to process for main files to work withot any issues. It first appeared in 2012 as an other choice to Browserify which was the most popular module bundler at that time. Webpack took that place in 2015. `","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":36,"value":"topic_head('Creating the basic project which uses Webpack')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":48,"value":"build_step('Creating the most basic configuration')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":38,"value":"md` ## Sample project\nWe have several ways to create the project, but let's look at the easiest one. We will use Node.JS, a JavaScript run-time environment that executes JavaScript code outside of a browser. We will create a simple Node.JS application which will include some code, dependencies and Webpack configuration. It is important to point out that everything here is applying to .NET Web Apps also. At the start, we will create a folder called _Meetup Application_ and then write the following command:\n\n\\`\\`\\`\nnpm init -y\n\\`\\`\\`\n\nWhat does each part do? The _npm init_ command is standard way to create a basic Node.JS application without any configuration. The __-y__ flag here simply means that Node.JS will skip asking any questions about the content of _package.json_ what means that it will create the easiest package.json file possible.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":43,"value":"$3d","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":50,"value":"$3e","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":76,"value":"topic_head('Writing the configuration')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":136,"value":"build_step('HTML')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":286,"value":"htmlGraph = html`

`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":175,"value":"$40","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":180,"value":"help_build_step('Adding webpack-dev-server')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":182,"value":"md`At the beginning, we need to install _webpack-dev-server_ via NPM:\n\n\\`\\`\\`\nnpm i webpack-dev-server -D\n\\`\\`\\`\n\nOne thing is important to point out at the beginning: you should use _webpack-dev-server_ only for __development__, for production you should use some more permanent solution such as Apache, IIS, Docker or any other solution.\n\nThe next step we need to do is using _webpack-dev-server_ in CLI. We need to go to __package.json__ and add _scripts_ section inside already existing JSON object:\n\n\\`\\`\\`\n\"scripts\": {\n \"start\": \"webpack-dev-server --mode development\",\n \"build\": \"webpack --mode production\"\n}\n\\`\\`\\`\n\nAnd voila! After that, all we need to do is run _npm start_ and see the magic happen. :) Also, try to __edit your index.js file and watch what happens__.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":668,"value":"md`Let's try it out:\n\nWe will once change our _index.js_ file to this, run Webpack and see what do we get:\n\\`\\`\\`javascript\nconst message = 'Hello world from .NET meetup! :)'\nconsole.log(message);\n\nconst element = document.createElement('h1');\nelement.innerHTML = message;\ndocument.body.appendChild(element);\n\\`\\`\\`\n\nYou can try to edit e.g. message and see how everything automatically changes.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":387,"value":"md`One another very useful option is defining WDS inside of _webpack.config.js_. That way we can get even more power:\n\n\\`\\`\\`javascript\n{\n // The rest of configuration ...\n\n devServer: {\n stats: 'errors-only',\n host: process.env.HOST, // Defaults to localhost\n port: process.env.PORT, // Defaults to 8080\n open: true, // Open the page in browser\n //writeToDisk: true // If we want to always save data on same location, we can uncomment and try this :)\n }\n\n // The rest of configuration ...\n}\n\\`\\`\\`\n\nThere are more possible settings, but these are the most common.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":382,"value":"md`But what do those modes mean? Webpack by default has 3 modes: _development_, _production_ and _none_. Each one of them has its own set of optimizations. Some things specific for each mode are:\n* __development__\n * Quicker building + rebuilding\n * Encouraged usage of dev server\n * Encouraged usage of HMR (Hot Module Replacement)\n* __production__\n * Minification (_Terser_, not _Uglify_ which has been deprecated since mid-2018)\n * Tree Shaking - Eliminating dead code, aka the code that is never called.\n * Application optimization (e.g. _scope hoisting_ for faster accessing the functions)\n* __none__\n * No optimizations are applied (leaving them completely up to user)`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":140,"value":"build_step('Loading JavaScript')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":409,"value":"help_build_step('Demonstrating the problem')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":395,"value":"$41","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":411,"value":"help_build_step('Adding Babel')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":414,"value":"md`To add Babel, we first have to install it. We can do that by writing the following command in the console:\n\n\\`\\`\\`\nnpm i @babel/core babel-loader @babel/preset-env -D\n\\`\\`\\`\n\nThe loaders above are for __Babel 7.x__, but if you are using __Babel 6.x__, you need to write the following:\n\n\\`\\`\\`\nnpm i babel-core babel-loader@7 babel-preset-env -D\n\\`\\`\\`\n\nWe will use the latest version, so we need the first command. _@babel/core_ is the main package which contains everything necessary for using Babel. _babel-loader_ is Webpack's loader for Babel, while _@babel/preset-env_ allows you to use latest JavaScript syntax without any catch like worrying about if it will work.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":420,"value":"md`We will update our Webpack configuration to include everything we need. We are gonna add the new section (property): _module_ where we will define _rules_ which tell Webpack how to handle different file types.\n\n\\`\\`\\`javascript\nconst path = require('path');\nconst rootPath = require('app-root-path').path; // app-root-path is NPM packages for locating the root part of \n// main NPM project from anywhere, check it out if you want to\n// ...\nmodule: {\n rules: [{\n test: /\\\\.(js|jsx)?$/,\n exclude: [path.join(rootPath, 'node_modules')],\n use: [{ // 'babel-loader' enough if we are not using any options\n loader: 'babel-loader',\n options: {\n presets: [\n '@babel/preset-env'\n ]\n }\n }]\n }]\n}\n\\`\\`\\`\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":498,"value":"$42","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":457,"value":"md`Obviously, there are much more options available like _plugins_ and many more. If you need any additional feature not yet available in _@babel/preset-env_, you can use plugins which you can define the similar way as presets. But, let's remove to older browsers, what about e.g. Internet Explorer 11 and array functions which it doesn't support at all?`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":142,"value":"help_build_step('Polyfills')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":461,"value":"$43","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":477,"value":"md`Presets can be passed as arrays of arrays as well! Here we are passing an object of options as 2nd element. For polyfills, we need to define 2 parts: browsers that need to be supported (inside of _targets -> browsers) and how should polyfills be added. Under _browsers_ we define supported browsers by using __browserslist__ syntax ([LINK for more info](https://www.npmjs.com/package/browserslist)). After that, we use _useBuiltIns_ to define if we want to include all polyfills (_entry_) or only the ones we use (_usage_), that is up to our needs. Now we have fully covered JavaScript as well, so let's move to CSS now!`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":144,"value":"build_step('Loading styles (CSS)')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":483,"value":"md`So, let's say that we want to add CSS to our HTML to give it some style and format. :) As we know already, Webpack knows how to process only JavaScript, so it's kinda obvious that we will have to include something additional for CSS. For the start, we need to install 2 NPM packages:\n\n\\`\\`\\`\nnpm i css-loader style-loader -D\n\\`\\`\\`\n\n_css-loader_ is quite obvious, it allows Webpack to read and transform CSS, while _style-loader_ allows injecting of CSS as HTML \\`\\`\\`\\`\\`\\` tag. So, how do we include it in _webpack.config.js_?\n\n\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":493,"value":"md`\n\\`\\`\\`javascript\nmodule: {\n rules: [\n // ...\n {\n test: /\\\\.css$/,\n include: [path.join(rootPath, 'src', 'styles')],\n use: ['style-loader', 'css-loader']\n }\n // ...\n ]\n}\n\\`\\`\\`\n\nWhat do we have here? We have usual parts: _test_ for recognizing necessary files, _include/exclude_ for knowing which files to check and list of loaders in _use_. But we have something new here, we have _multiple loaders_, how to read this? Webpack uses something similar to LIFO -> last loader will be executed first. So, this rule can be read as: \\`\\`\\`style(css(CODE))\\`\\`\\`.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":675,"value":"md`We can try to add new folder _styles_ inside of _src_ and there we can create a new file called _style.css_. From there all we need to do is define something, import it in JS file and try to run the configuration.\n\ne.g.\n\\`\\`\\`css\nhtml {\n background-color: gainsboro;\n}\n\\`\\`\\`\n\nAnd then add the following line to _index.js_:\n\\`\\`\\`css\nimport './styles/style.css';\n\\`\\`\\`\n\nAnd after that you can write _npm start_!\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":673,"value":"md`But, what if we don't want CSS to be inside of HTML, if we want to have it in separate file? And if for example we wanna minify the file in production?`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":146,"value":"help_build_step('Extracting and minifying CSS')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":512,"value":"md`Webpack can do that as well! The first thing we need to do is install necessary dependencies:\n\n\\`\\`\\`\nnpm i mini-css-extract-plugin optimize-css-assets-webpack-plugin -D\n\\`\\`\\`\n\nThe _mini-css-extract-plugin_ package is used for extracting CSS from JavaScript bundles into separate files, while _optimize-css-assets-webpack-plugin_ is used for minifying the CSS what should improve your page loading. Let's see how to use it:\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":518,"value":"md`Due to simplicity, let's first look at how to add _mini-css-extract-plugin_ and then we will focus on _optimize-css-assets-webpack-plugin_.\n\n\\`\\`\\`javascript\nconst MiniCssExtractPlugin = require('mini-css-extract-plugin');\n\n// ........\n\nmodule: {\n rules: [\n // ...\n {\n test: /\\\\.css$/,\n include: [path.join(rootPath, 'src', 'styles')],\n use: [MiniCssExtractPlugin.loader, // Just as adding HTML, we need extracting to be executed last\n 'css-loader']\n }\n ]\n}\n\n// ...\nplugins: [\n // ...\n new MiniCssExtractPlugin({\n filename: 'css/[name].css' // We need to specify at least a file name\n })\n],\n\\`\\`\\`\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":523,"value":"md`First we have to require _mini-css-extract-plugin_ since we are not using it as string. Then we need to replace \\`\\`\\`style-loader\\`\\`\\` with \\`\\`\\`MiniCssExtractPlugin.loader\\`\\`\\` which is the default loader for extracting CSS from JS bundles. Additionally, we need to head to _plugins_ and add \\`\\`\\`MiniCssExtractPlugin\\`\\`\\` because we need to specify at least a file name.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":527,"value":"md`For _optimize-css-assets-webpack-plugin_ to work, we have to add it to the different place:\n\n\\`\\`\\`javascript\nconst OptimizeCssAssetsWebpackPlugin = require('optimize-css-assets-webpack-plugin');\n\n// ........\n\noptimization: {\n minimizer: [\n new OptimizeCssAssetsWebpackPlugin({})\n ]\n}\n\n\\`\\`\\`\n\nSince Webpack 4.x, all things related to optimization of application and/or minifying files go under _optimization_ section/property. Here we are using the CSS minimizer for production, so we just need to tell Webpack to run it and that's it! Let's try all of this by running _npm run build:dev_ & _npm run build_ to see if everything is really minimized whenever necessary.\n\nWhile you are doing this, it is necessary to be aware that this approach may be a _little bit slower_ than __style-loader__, but you need to think about which case you need.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":532,"value":"help_build_step('Advanced stylesheet languages')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":534,"value":"md`So, as we know already, CSS is a stylesheet language most widely used. There are more advanced stylesheet languages we can use and Webpack has support for all of them as well!\n\nSome of more popular advanced stylesheet languages are _SASS_, _LESS_, _Stylus_ and more. Webpack has loader available for each one of them, so it is not hard to use them. I won't get into usage now, but basically everything you need to do is:\n1. Install necessary NPM package for whichever stylesheet language you are using apart from CSS (e.g. _sass-loader_)\n2. Install any necessary additional loaders (e.g. resolving URLs by using _resolve-url-loader_ or advanced CSS transforming by using _postcss-loader_)\n3. Include in Webpack\n\nWhen you are adding it to Webpack, keep an eye at the following order of loaders:\n1. Extracting CSS / style-loader (should be executed last)\n2. css-loader (transform whatever you are using into CSS)\n3. Any other loaders (sass-loaders, resolve-url-loader, postcss-loader, etc.)\n\nAnd you will be ok. :)`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":148,"value":"build_step('Loading files')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":542,"value":"md`Currently we have JavaScript, HTML, CSS and development server, but what if, for example, we wanna add some files? How would we handle that? By using webpack, of course! For the start, we need to install necessary dependencies:\n\n\\`\\`\\`\nnpm i file-loader url-loader -D\n\\`\\`\\`\n\nThe _file-loader_ NPM package is quite obvious, but _url-loader_ encodes your file content (e.g. into base64) wherever it is necessary, but there are some conditions that are recommended to be set up. Let's look at this:\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":548,"value":"md`We will once again head to our _webpack.config.js_ file and add the new rule under _module -> rules_:\n\n\\`\\`\\`javascript\n// ...\nmodule: {\n rules: [\n // ...\n {\n test: /\\\\.(jpe?g|png|gif|svg|ico)(\\\\?.*$|$)$/i,\n include: [path.join(rootPath, 'src', 'assets')],\n use: [{\n loader: 'url-loader',\n options: {\n limit: 10000,\n publicPath: '../',\n name: '[sha512:hash:hex:9999].[ext]'\n }\n }]\n }\n ]\n}\n// ...\n\\`\\`\\`\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":552,"value":"$44","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":150,"value":"build_step('webpack-merge')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":435,"value":"md`Let's say that we have 2 JavaScript objects:\n\\`\\`\\`javascript\n{ a: [1], b: 5, c: 20, e: {i: 25} }\n\n{ a: [2], b: 10, d: 421, e: {j: 28} }\n\\`\\`\\`\n\nWe will use _webpack-merge_ to merge those 2 objects together:\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":433,"value":"merge( { a: [1], b: 5, c: 20, e: {i: 25} }, { a: [2], b: 10, d: 421, e: {j: 28} } )","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":443,"value":"md`Some will say, _\"But we have Object.assign and object rest spread which does the same thing!\"_ Wrong! Rest spread can merge the objects and arrays, but if we have same key in multiple objects, it will only use the last key-value pair. Check it below: `","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":445,"value":"Object.assign( { a: [1], b: 5, c: 20, e: {i: 25} }, { a: [2], b: 10, d: 421, e: {j: 28} } )","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":448,"value":"md`You can see that it's not the same! Basically, my point here is that we can use webpack-merge as demonstrated above to split configuration into multiple objects to make it easier to follow. With that we will also avoid breaking DRY (_Don't Repeat Yourself_) principle because we have a lot of parts that are common for development and production. Since this is a bit more complex, I won't get into setting this up here, so feel free to check the project for more info!`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":152,"value":"build_step('Bundle splitting')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":603,"value":"help_build_step('Duplicate code issues')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":563,"value":"$45","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":560,"value":"md`Apart from Webpack configuration, there is one more case where repeating is possible and that is in generated bundles. Let's imagine that we have multiple entry points like the 2 entry points above. Let's also imagine that our project has multiple dependencies. We can see that we have _react_ and _react-dom_ dependencies in both projects. Why is that not good?\n* Code repeating: According to [BundlePhobia](https://bundlephobia.com/), React + React DOM together have 6.5 + 102.7 = 109.2 kB of minified code and we have to include it in multiple entry points. If some of your clients has slow internet, it can affect page load time if both entry points are used at the same page.\n* Code changes: Unless you change some version, all dependencies (including _react_ and _react-dom_) are part of the code that doesn't change with every release unless you change the version and still the code has to be downloaded again because other parts of the bundle changed.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":592,"value":"md`How to sort this out? Webpack has very useful feature called _bundle splitting_ which allows you to separate the common parts of each entry point into a new bundle file. You can also e.g. separate all imported _node_modules_ packages into separate bundle file. In Webpack 3.x and earlier this feature was called _CommonsChunkPlugin_, but now it has a new name: _splitChunks_. Let's see how we can use it.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":601,"value":"help_build_step('Automatic splitting common parts into separate bundle')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":596,"value":"md`We need to update our Webpack configuration what again means editing the configuration (_webpack.config.js_ or wherever you have put your configuration). Let's first split the commonly used parts into separate file:\n\n\\`\\`\\`javascript\n// ...\noptimization: {\n splitChunks: {\n chunks: 'initial'\n }\n}\n// ...\n\\`\\`\\`\n\nSo, now when we run Webpack build, we can see that we get separate _vendors_ file which contains everything commonly used across all of our entry points. The only thing we need to define under _splitChunks_ is which chunks should be selected for optimization: all, async or initial (aka non-async).\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":605,"value":"help_build_step('Controlling the bundles')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":607,"value":"$46","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":611,"value":"md`If we want to go a bit different way, there is another possible option in Webpack: _code splitting_ by using lazy loading. What does that mean? Well, basically, we load the parts of the code only when we need it. That is very useful if we e.g. have the web page that should be as optimized as possible, so we wanna load several parts of the application only when they are absolutely necessary.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":613,"value":"help_build_step('Final result')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":615,"value":"$47","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":622,"value":"md`So, as a final result, we get an application which uses the shared vendors as separate script!`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":624,"value":"topic_head('Webpack vs. everything else?')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":628,"value":"build_step('Webpack vs. task runners')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":630,"value":"md`Today you often can hear statements like: \"_Why should I use Webpack when I have Grunt and Gulp which can do the same thing?_\" Is that true? __No.__\n\nAs we saw in the beginning, Webpack takes the entry files and checks what is necessary and then adds all of that. Grunt and Gulp are not that _smart_ since they are task runners. They don't know how to _read_ the files, they only know to do what you tell them to do and it's often something like: minify those JS files, combine them into one, copy those images, ... We may get one bundle with Grunt and Gulp, but it is just multiple files mashed into one without any checking, like mashed potatoes.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":633,"value":"build_step('Webpack vs. Parcel')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":635,"value":"$48","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":641,"value":"topic_head('Conclusion')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":643,"value":"md`Let's sum up everything: :)\n\n## Advantages\n* Very customizeable and offers a lot of options\n* Good documentation and everything is very-well defined\n* Eliminates worrying about \"_including all the necessary dependencies_\"\n* Can be used to optimize anything that is necessary --> in terms of bundle size, browser support, etc.\n* Very big community, so you can find the answer to anything you need\n\n## Disadvantages\n* Often gets the rep for being \"_too complicated_\" to use, so people tend to avoid setting it up\n* Limited support out-of-the-box for running Webpack with no configuration: it supports only ES2015\n* This also means that it requires configuration for most of the cases\n* Some features such as _bundle splitting_ or _code splitting_ can be trickier to set up, so they may take you time`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":4,"value":"import {topic_head, build_step, help_build_step } from \"@antetmc2/elements\"","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":160,"value":"dot = require(\"@observablehq/graphviz@0.2\")","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":273,"value":"d3 = require(\"d3-graphviz\", \"d3-selection\", \"d3-transition\")","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":303,"value":"htmlGraphviz = d3.graphviz(htmlGraph)\n .transition(() => d3.transition().duration(1000))\n .engine('neato')\n .zoom(false)\n .width(300)\n .fit(true)\n .renderDot(`digraph {\nnode [style=filled]\n1[label=\"PROJECT\", fillcolor=\"#34acdb\", fontname=Calibri, fontsize=20, pos=\"0,2!\"];\n2[label=\".JS\", fillcolor=\"#eaa327\", fontname=Calibri, fontsize=20, pos=\"0,1!\"];\n3[label=\".HTML\", fillcolor=\"#ed4747\", fontname=Calibri, fontsize=20, pos=\"2,1!\"];\n4[label=\"HOW?\", fillcolor=\"#f27d7d\", fontname=Calibri, fontsize=22, pos=\"2,0!\"];\n\n1 -> 2\n2 -> 3\n3 -> 4\n\n}`)\n .on(\"end\", () => d3.select(htmlGraph).dispatch(\"load\"))\n .zoom(false)","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":334,"value":"developmentProcessGraphviz = d3.graphviz(developmentProcessGraph)\n .transition(() => d3.transition().duration(1000))\n .engine('neato')\n .zoom(false)\n .width(450)\n .height(150)\n .fit(true)\n .renderDot(`digraph {\nnode [style=filled]\n1[label=\"Write Code ...\", fontname=Calibri, fillcolor=\"#e84748\", pos=\"0,0!\"];\n2[label=\"Save the File\", fontname=Calibri, fillcolor=\"#38ade0\", pos=\"0,1!\"];\n3[label=\"Run Webpack\", fontname=Calibri, fillcolor=\"#34c134\", pos=\"3,1!\"];\n4[label=\"F5 in Browser\", fontname=Calibri, fillcolor=\"#ea852c\", pos=\"3,0!\"];\n\n1 -> 2\n2 -> 3\n3 -> 4\n4 -> 1\n} `)\n .on(\"end\", () => d3.select(developmentProcessGraph).dispatch(\"load\"))\n .zoom(false)","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":430,"value":"merge = require('https://bundle.run/webpack-merge@4.2.1')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":93,"value":"md``","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"}],"files":"$W49","stdlib":"1"}} 33:null