34:["$","title",null,{"children":"Introduction to modern Web development with Webpack 4 | Ante Tomić | Observable"}] 3c:T415,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. Websites are getting smarter and bigger and more complex, so all inventions are always important. From only HTML, CSS and JavaScript and having to including everything manually, we have come really far with Web development thanks to people searching for better solutions. Today there are a lot of ways to make a website what makes our job possibly easier, but also more complex because we need to be caught up with much more things than before. In addition to the new inventions, there are some additional issues 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. Because of all those issues, it is getting much harder to develop a new application without several parts such as generating the code output, but luckily one of the possible solutions is _Webpack_. Let's look into it more!`3d: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] } `3e:T457,md`Webpack is a module bundler. Imagine a JavaScript entry point with imports. Webpack here processes all the files, checks what's necessary for Web page to normally open and only includes things where it had to go to (AKA inside of all _imports_). But, we can see different colors here. Those colors represent different file types or more precisely, different loaders that are necessary. For JavaScript we use the one set of loaders, for CSS we use the one set, while for any images or fonts we use the one set of loaders. Because Webpack by default can process only ES2015, most likely we will have to define a Webpack configuration (_webpack.config.js_) in order for Webpack to be able to process all the unknown file types. Generally, we also have to be sure that generated bundles will contain only stuff that is really necessary, but more about that soon. Final result is generated code that can be opened in the browser without any problems. Module bundlers first appeared in 2012 as another choice to Browserify which was the most popular module bundler at that time. Webpack took that place in 2015. `3f:T526,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_ + _index.js_ where we will put this JavaScript code: \`\`\`javascript console.log('Zašto NASA šalje Mišu Kovača na Mars? Jer jedini može napraviti atmosferu!'); \`\`\` The _src_ folder is where Webpack looks for entry points by default and you don't have to specify anything for Webpack to check at that location. We will start simple ${html`😄`}. To make things easier, add this to _package.json_: \`\`\` "scripts": { "build": "webpack" } \`\`\` We will come back to scripts 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 to _dist_ folder and with this we got the first JavaScript output bundle file! `40:T4ce,md`There are four important concepts for Webpack configuration: ## Entry Points Here we define where are our starting points located inside of project files. By reading the _entry_ property in Webpack configuration it knows where to look for the files. ## Output Here we can define where we want the generated code bundles to be stored. By default Webpack saves to _dist_ folder, but you can define naming convention or even desired folder name. There are even more settings available in Webpack documentation which can help you in defining desired output as well. ## Loaders Since Webpack by default can transpile only part of ES2015 syntax, you will have to add loaders which are transpilers to _teach_ Webpack how to process different file types. It is expected that every file format you use will have available loader, but it is best to check Webpack documentation which includes intructions for most common loaders. ## Plugins With plugins we can add additional functionality to Webpack. If e.g. we need to minimize CSS, generate HTML output or minimize JavaScript output, it is a good idea to check plugins. Additionally, feel free to check environments as well because they include some of plugins enabled by default. `41:T59f,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 only updates the changed files. So, what else? Maaaybe development server? There is __webpack-dev-server__ which supports everything necessary! Then as soon as we start the application, we can start it like it is deployed and access application locally via _localhost_. But, depending on how we have everything set up, we can also set up proxying by using Webpack options, so when we make some request, it will be sent to the real backend server, while URL in our application will be converted to the proxied one. Additionally, WDS also supports _Hot Module Replacement_ which allows you to update the application on runtime without forcing a new refresh. It is great for productivity and it can be used even with stylesheets. You can check out more about it in Webpack documentation, but it is really _cool_ and _useful_ feature. :)`42:T463,md`If you are using webpack-dev-server, you can use one of the most useful Webpack features: _Hot Module Replacement (HMR)_. It allows you to update everything on runtime without the need for full refresh in browser when you save the changes. It is available for using in stylesheets such as CSS, SASS and more or in JavaScript and frameworks like React and more. It is important to point out that you should use it for development only. It is not intended to be used for production, but in development it can help you in quicker development because: * You retain full application state. Usually, if you update something, you have to reload the page and because of that you lose everything potentially saves to application state. * You update only changed things inside of browser, while everything else is left unchanged * Changes are almost instant, like using Developer Tools in Chrome. As soon as you save the changes, Webpack build reloads and as soon as it finishes, you can see updates in your browser. You can read more about Hot Module Replacement [HERE](https://webpack.js.org/concepts/hot-module-replacement/)`43:T640,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 with this: \`\`\` "scripts": { "start": „webpack-dev-server –mode development”, "build:dev": „webpack –mode development”, "build": „webpack –mode production” } \`\`\` We see that everything works in browser, but let's check the output! We can see that Webpack generated output that contains _const_ and that may not work well with older browsers. There is a website called __Can I Use...__ that can help with this, so let's check it for _const_: [LINK](https://caniuse.com/#search=const). Also, when we come to think a bit better, definition of what is JavaScript today is different as well. Today JavaScript is full of new and cool features (from EcmaScript specification) such as arrow functions, object rest spread syntax, various functions such as array functions, async/await functions with promises and many more. If we check _caniuse.com_, we can see that anything _not_ green is either partially or not supported. In our example, as much as we don't like Internet Explorer 6 - 10, we can see that it doesn't support const, so we need to convert this to something browsers can read. We can also have similar issues with newer functions and latest versions of browsers, so it is very useful to bookmark this page. We can solve this issue with __Babel__ which is the JavaScript code compiler that converts any JavaScript syntax to something browsers can read. `44:T47c,md`What does each part do? Here _rules_ is an array of objects with definitions for specific rule. Here we are defining that Webpack should use this rule for JavaScript filesy 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 used loaders. It is either a simple string (only one loader), an array of strings (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 loader options go under _options_ which is unique for each loader type. Here we need to tell Babel to use _@babel/preset-env_ by defining presets to use the latest JavaScript syntax. After we run the configuration, we can see that we have now received _var_ instead of _const_, so we know that Babel is working!`45:T716,md`By definition, polyfills represent the code that implements something that Web browsers don't support yet (older versions of browsers ... and _Internet Explorer_). For example, let's check array functions: [LINK](https://caniuse.com/#search=array). 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 a 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 (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' }] ] } }] }] } \`\`\` `46:T67b,md`In addition to everything mentioned, you can also additionally optimize CSS output by using _PostCSS_. Webpack has the support for it through _postcss-loader_. PostCSS is CSS preprocessor used to transform CSS by using JavaScript. While the tool itself doesn't contain a lot of stuff, plugins are where its power really is. There is a really big collection of plugins available and some of the most popular ones are: * _Autoprefixer_ - Increase code readability by browsers by ensuring that used syntax is supported by them. It parses your code and checks if any of the rules need vendor prefixes. Similar to polyfills, data from _caniuse.com_ is used to determine that. * _postcss-preset-env_ - The best description for it is that it is CSS's Babel. It allows you to use modern CSS features while it takes care of transpiling them to a CSS more digestible to older browsers. It also uses _Autoprefixer_ to add add prefixes, so you don't have to use Autoprefixer directly! Some of modern CSS features you can use are: * CSS grids * CSS variables * Nesting (like in SASS) * Media query ranges and many more * _Stylelint_ - Same like ESLint and TSLint, you can use Stylelint to check your CSS for code consistency and bugs in literally the same way like in ESLint and TSLint. It also supports automatic fixing of several rules, so it can save you time on manual fixing of errors. Additionally, you can lint SASS as well. * _LostGrid_ - You can use this powerful grid system to generate a grid system in any preprocessor or even vanilla CSS. There are properties defined you can use and according to which the necessary CSS is generated as a result.`47:T5b5,md`We are defining the usual: _test_ where we define regex to check images, _include/exclude_ which are recommended here to optimize build time and loaders. The only specific thing is _url-loader_ which, together with _file-loader_, opens many possibilities. When we are using _url-loader_ there are 2 recommended settings: __name__ with 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_ (default: __file-loader__). If we want to, we can use _file-loader_ directly and in that case we don't need _url-loader_ dependency. Add a new folder called _assets_ inside of _src_ where we will add the picture! Now add the image by adding this to the end of 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 run our Webpack configuration! 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 features. :)`48:T44b,md`When we are including files that are images, it is possible that one of the included images will be too big either in resolution or in size. Then we will need to resize or compress that image to keep our page load time ok. If we need to only resize an image, that can easily be done with CSS only without manually changing the image. But, if we need to compress the image without e.g. losing the image quality, we can use _image-webpack-loader_. It is Webpack's loader specified for JPEG, PNG, SVG and GIF images, but it additionally supports converting to WEBP images as well. When using the loader, you can use the default settings used for different file types or you can override them, but before using this, please think about this: __do you need to optimize your images through the Webpack build?__ If you don't have a lot of images, it may be enough to do this without installing _image-webpack-loader_ because it really adds a lot of dependencies you most likely won't need. In addition to all of that, your build time will be longer because it needs to install all those dependencies.`49:T4d4,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=gold3, fontcolor=gold4, fontname=Calibri, shape=doubleoctagon]; 10[label="mobx", color=azure3, fontcolor=azure4, fontname=Calibri]; 11[label="react-select", color=azure3, fontcolor=azure4, fontname=Calibri]; 12[label="moment", color=gold3, fontcolor=gold4, fontname=Calibri, shape=doubleoctagon]; 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 4 -> 12 } `4a:T486,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="react", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 9[label=" ", color=darkorange, fontcolor=darkorange2, fontname=Calibri]; 10[label="react-dom", 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]; 14[label="moment", color=darkorange, fontcolor=darkorange2, 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 7 -> 14 } `4b:T494,md`Let's say that we have a file like this one \`\`\`javascript import { something } from "./something"; function usingSomething() { return something; } export function test() { return usingSomething(); } \`\`\` With changes in Webpack 5 related to inner-module tree shaking, that means that inner graph algorithm can analyze how imports are used. Here algorithm will notice that _something_ is used only when the exported function _test_ is used. This means that, whenever _test_ is not used, _something_ can be removed ... but wait, **usingSomething** uses something as well. This function is called a side effect which in the scope of Webpack represents code that performs an action when imported, but which is then not imported anywhere. We can actually set in _package.json_ if we want to keep side effects in the code and Webpack will listen. It looks like this: \`\`\`json { "name": "your-project", "sideEffects": false } \`\`\` In this case this means that the __whole file__ can be removed if we have set side effects to be removed safely. This can massively help you as well because you can have only stuff that is really necessary. `4c:T557,md`Webpack as a module bundler transforms files to the format suitable for opening in a browser. It takes the list of entry files, go through them and builds up a _dependency graph_. That dependency graph shows Webpack what each file needs and in which order, so that it can be opened in the browser without any issues. It doesn't work for JavaScript only, it is possible to build a dependency graph for multiple different file types. Regarding task runners, ironically you would expect module bundler to be closely used with task runners, but that's not the case here. Earlier you could use task runners for actions such as source maps or minification or something similar, but Webpack and any other module bundler today is advanced enough to be able to do this on its own and that eliminates the necessity for task runners. It is still possible to combine Webpack with task runners for some actions that are not that integrated like linting and testing, but people still opt not to use the task runners because it's not necessary. You can use _package.json_ scripts for any of those actions because you will most likely have only build scripts for development/production and any additional actions such as linting and testing. Additionally, there are a lot of CI (continuous integration) solutions available such as Jenkins Pipelines, build scripts and many more.`4d:Teb8,md`Feature|Webpack|Parcel|Rollup --------|---------|---------|----------- Build without configuration|${html`limited`}|${html`yes`}|${html`no`} HTML entry point|${html`no (only HTML generation)`}|${html`yes`}|${html`with plugin`} Development server|${html`plugin`}|${html`embedded`}|${html`plugin`} Hot Module Replacement|${html`yes`}|${html`yes`}|${html`no`} Tree Shaking|${html`yes`}|${html`yes`}|${html`yes`} Code Splitting|${html`yes`}|${html`yes`}|${html`yes`} Bundle size|${html`~2nd`}|${html`~2nd`}|${html`1st (excellent tree shaking)`} Dev experience (from easiest)|${html`2nd`}|${html`1st`}|${html`3rd`} Learning curve|${html`takes some time`}|${html`for beginners`}|${html`longest`} Build tweaking/customization|${html`yes`}|${html`questionable (possibly too new)`}|${html`complicated`} Complex apps|${html`yes`}|${html`no (possible issues)`}|${html`yes (but harder to use)`} Recommendation|_default_|_simple use cases / beginners_|_libraries / smaller bundle sizes_ `4e:[] 38:{"id":"69639a36d544a59a","slug":"introduction-to-modern-web-development-with-webpack-4","title":"Introduction to modern Web development with Webpack 4","thumbnail":"bb64c73b4315fa28e72ee86bd22f717a2686858d9be9e8c71349caa068f4f28c","access_level":"public","create_time":"$D2019-03-18T19:55:55.887Z","update_time":"$D2019-10-25T05:09:15.488Z","view_time":null,"first_public_time":"$D2019-05-13T18:11:27.887Z","has_unpublished_edits":null,"fork":{"id":"16db81cf98d0b003","slug":"introduction-to-packing-and-building-applications-with-we","title":"Introduction to packing and building applications with Webpack 4","owner":{"id":"fd1b77499a80fc6b","login":"antetmc2","name":"Ante Tomić"}},"stars":7,"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":1130,"publish_version":1130,"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":5,"collection":null,"type":"notebook","body":{"titling":"auto","title":"Introduction to modern Web development with Webpack 4","cells":[{"id":0,"value":"md`# Introduction to modern Web development with Webpack 4\n## For JavaScript meetup\n\n## Description:\n\nAre you familiar with developing apps and having to be careful to \"include that script before your own because the application won't work\"? Or have you ever used Webpack or similar solutions and wondered how they work? Here we will explore the concepts necessary to build an application from no setup code to the most common Webpack concepts. We will also see how Webpack relates to the other popular solutions like Parcel or task runners such as Gulp or Grunt, and say a few words about Webpack 5 and what is next to come.\n\nP.S. 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`Code example (from another meetup with same topic): [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":27,"value":"topic_head('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":"$3c","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":"$3d","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":33,"value":"$3e","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 will use Node.JS, a JavaScript run-time environment that executes JavaScript code outside of a browser. We will make a simple Node.JS application which will include code, dependencies and Webpack configuration. We will first create a folder with any name and then write the following command:\n\n\\`\\`\\`\nnpm init -y\n\\`\\`\\`\n\nThe _npm init_ command is the standard way to create a basic Node.JS application without any configuration. The __-y__ flag here simply says that Node.JS will skip asking any questions about the content of _package.json_ and just create it.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":43,"value":"md`## Installing the dependencies\n\nTo start with Webpack, we need to install the necessary dependencies. There are 2 dependencies necessary for Webpack 4.x: _webpack_ and _webpack-cli_. \n\nWhy 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:\n\n\\`\\`\\`\nnpm i webpack webpack-cli -D\n\\`\\`\\`\n\nWe are using the standard NPM install function (_npm install_ or shorter _npm i_) which installs the dependencies. Since this is dependency for build time, I am putting it in devDependencies by specifying the __-D__ flag or longer __--save-dev__. For production (code necessary for runtime), use __-P__ flag or longer __--save__.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":849,"value":"md`## Creating the sample code\n\nThen we open a folder called _src_ which we will use to create JavaScript files we will process with Webpack. This folder is default location where Webpack first looks for JavaScript files. You are also allowed to define entry points which you can then use to define desired names and used files, but in that case Webpack won't look at _src_ folder anymore!\n\nYou can check an example for how to write the sample code below.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":50,"value":"$3f","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":856,"value":"md`### Package.json scripts\n\nI just wanted to share one tip: _use package.json scripts whenever possible_. Generally, some of NPM packages you use in your project will have defined CLI commands. Those are commands you can use inside of your project, but when you try to run then directly inside of your project, something is not working!\n\nFeature that comes to the rescue are package.json scripts! Thanks to all NPM packages you are using and their CLI commands, you can define custom NPM scripts that are then available as a command you can run directly from your console. A good example is _build_ script below which you then use as _npm run build_.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":868,"value":"topic_head('Starting to build up the configuration')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":871,"value":"md`We managed to get some JavaScript output with out-of-the-box configuration. Without any configuration, we can transpile part of ES2015 code and that's it. We will see this in an example, but trust me on this for now. We don't get support for ES6, ES2017, ES2018 or any newer syntax, we don't even have CSS support for example. As we concluded, Webpack supports very limited out-of-the-box configuration, what means that it will still require writing the configuration most of the time. Let's check out how we will do that.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":878,"value":"build_step('Creating webpack.config.js')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":881,"value":"md`For the start, we will create Webpack configuration file with default location and name. This means the following:\n* File is called _webpack.config.js_\n* File is located in same folder where _package.json_ is located\n\nAll of those settings represent where Webpack checks by default, so you don't have to explicitely define anything. But, if you want to do anything additionally, you have to define that either in CLI or in Webpack configuration. My suggestion is to use the latter as it's easier to read than inside of console/scripts.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":886,"value":"build_step('4 important concepts')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":892,"value":"md`\\`\\`\\`javascript\nmodule.exports = {\n entry: { ... },\n output: {\n filename: '[name].js',\n path: 'public/'\n },\n resolve: {\n modules: ['node_modules'],\n extensions: ['.js', '.jsx', '.ts', '.tsx', '.css', '.scss']\n },\n module: {\n rules: [ ... ]\n },\n plugins: [ ... ],\n optimization: { ... }\n };\n\n\\`\\`\\``","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":889,"value":"$40","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":"$41","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\nRemember one thing: 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 is using _webpack-dev-server_. We need to go to __package.json__ and modify _scripts_ section:\n\n\\`\\`\\`\n\"scripts\": {\n \"start\": \"webpack-dev-server --mode development\",\n \"build\": \"webpack --mode production\"\n}\n\\`\\`\\`\n\nAnd voila! After that, run _npm start_ and see the magic happen. :) Also, try to __edit your index.js file and watch what happens__ after saving the file.\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 // ...\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}\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":921,"value":"help_build_step('Using Hot Module Replacement')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":924,"value":"$42","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":918,"value":"help_build_step('Webpack modes')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":382,"value":"md`What are those modes? Webpack has 3 modes: _development_, _production_ and _none_. Some of 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('What is JavaScript today?')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":395,"value":"$43","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__ (LATEST VERSION), 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. _@babel/core_ is the main package with everything necessary for Babel. _babel-loader_ is Webpack's loader for Babel, while _@babel/preset-env_ allows you to use the latest JavaScript syntax.\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":"$44","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 move 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":"$45","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! Here second element is an object of options. For polyfills, we need 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 supported JavaScript for any HTML file, 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":915,"value":"build_step('TIP: Source maps')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":912,"value":"md`If you want to, you can also use __source maps__. While you are developing an application and you start it in _development_ mode by using webpack-dev-server, you can notice that it is becoming harder to track down errors. To help with this, we can use __source maps__ which are another very useful feature. Depending on desired mode (environment), we can define how defined do we wanna source maps to be. We do that by using _devtool_ property which we can define right after devServer property: \n\\`\\`\\`javascript\n{\n // ...\n devtool: 'cheap-source-map'\n // ...\n}\n\\`\\`\\`\n\nYou can read more about it [HERE](https://webpack.js.org/configuration/devtool/).`","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, now we want to add CSS to our HTML to give it some style and format. :) Webpack knows how to process only JavaScript, so it's kinda obvious that we will have to include something additional for CSS. 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 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\nWe have _test_ for defining necessary files, _include/exclude_ for knowing which files to check and list of loaders in _use_. But we have _multiple loaders_??? Webpack uses something like LIFO -> last loader will be executed first, so -> \\`\\`\\`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 want to separate CSS? 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, // Instead of style-loader\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 need to require _mini-css-extract-plugin_ since we are not using it as string. Then we are replacing \\`\\`\\`style-loader\\`\\`\\` with \\`\\`\\`MiniCssExtractPlugin.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 name of our file.`","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, everything optimization-related goes under _optimization_ section. 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 check this with _npm run build:dev_ & _npm run build_.\n\nIt is necessary to be aware that this approach may be a _little bit slower_ than __style-loader__, so be cautious!\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`As we know already, CSS is the most popular stylesheet language and there are more advanced solutions Webpack supports!\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":935,"value":"help_build_step('Additional optimization of CSS output')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":938,"value":"$46","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 we wanna add some files? 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. _url-loader_ encodes your file content (e.g. into base64) wherever it is necessary, but there are some recommended conditions. 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":"$47","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":948,"value":"build_step('Optimizing images')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":953,"value":"$48","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":"$49","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: bundles. Imagine multiple entry points like the 2 entry points above. Let's also imagine that our project has multiple dependencies. We can see same dependencies in both entry points. Why is that not good?\n* Code repeating: According to [BundlePhobia](https://bundlephobia.com/), React + React DOM + Moment.JS together have 6.5 + 102.7 + 65.9 = 175.1 kB of minified code across multiple entry points. If some of your clients has slow internet, it can affect page load time.\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 and 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 a useful feature called _bundle splitting_ which allows you to separate the common parts 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 is called _splitChunks_. Let's check it out.`","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. 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\nQhen we run Webpack build, we can see the separate _vendors_ file with everything used in multiple places. The only thing we need to define under _splitChunks_ is which chunks should be selected: 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":"md`The other possible solution is controlling what is separated. This is different because it specifically says to Webpack what to split. It also satisfies the second point which eliminates the unnecessary downloads.\n\nLet's look at how we can add it (instead of automatic splitting):\n\n\\`\\`\\`javascript\n// ...\n optimization: {\n splitChunks: {\n chunks: 'initial',\n cacheGroups: {\n default: false,\n vendors: {\n test: /node_modules/,\n name: \"vendors\",\n },\n },\n },\n }\n// ...\n\\`\\`\\`\n\nHere we define cache groups which represent something similar to entry points. Different cache groups can generate new files. Like for loaders, first we define under _test_ which files we want to separate, then we define the name of our chunk under _name_ and under _chunks_ we define which chunks should be chosen for optimization with the same options (all/async/initial).\n`","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":"$4a","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":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":965,"value":"md`We can apply bundle splitting to the configurations as well. When working on our application, we will need to define our build and that build will always be specific for development and specific for production. Because of that, when working on our build, we will either have one file with many checkups for environment or two files (one for development and one for production). Those configurations can then get quite complicated, messy and so big that all of that makes reusability or even reading of them harder. Additionally, they will have _repeated parts of code_.\n\nNow, since we know that something is either universal or for development or for production, we can use that idea for splitting up configuration into multiple files by using _webpack-merge_, a little library that can help you with configuration splitting! The result of using _webpack-merge_ is Webpack config object received from combining multiple parts into one. Let's check an example:` ","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":611,"value":"md`There is another possible option in Webpack: _code splitting_ by using lazy loading. What does that mean? 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":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":1060,"value":"topic_head('Webpack 5')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1063,"value":"md`Even though Webpack 4 has been out for quite a while, that doesn't mean that Webpack team wasn't busy. They have been actively working on Webpack 5 and the first beta version was finally released on October 11, 2019. Full and major release should follow up soon and it will focus on optimizing the developer experience by making things go smoother! There are a few very useful features, so let's now dive in into them:`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1068,"value":"build_step('Persistent caching')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1071,"value":"md`Before now, if you want to optimize the application build, you would have to use something like _cache-loader_ on specific file types or _hard-source-webpack-plugin_ for caching results in node_modules to have faster rebuilds, but all of those libraries are not something integrated into Webpack, they are external libraries you have to install separately. And some like _hard-source-webpack-plugin_ had a lot of problems in some versions of Webpack.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1075,"value":"build_step('Tree shaking')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1078,"value":"md`Tree shaking is something that has been existing in Webpack for quite a while. For those not familiar, _tree shaking is a method of optimizing code bundles by eliminated code the the file (called **dead code**) which is not used_. This can especially be visible in dependencies like Lodash or Moment.JS which have a lot of parts out of which some are most definitely not used. Let's be realistic, we will never use absolutely everything in Lodash and Moment.JS and that's why Tree Shaking is useful.\n\nWhy am I mentioning this? Because, Webpack has been working on improving Tree Shaking together with Code Generation (which represents _how should the code be generated_, so let's dive into this.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1082,"value":"help_build_step('Nested tree shaking')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1087,"value":"md`Let's say that we have a file like this one\n\\`\\`\\`javascript\n// inner.js\nexport const a = 1;\nexport const b = 2;\n// module.js\nimport * as inner from \"./inner\";\nexport { inner }\n// user.js\nimport * as module from \"./module\";\nconsole.log(module.inner.a);\n\\`\\`\\`\n\nNested tree shaking means that Webpack is analyzing each import and is actually checking which properties are used, even if all of them are imported. Here in this example we can see that only **a** is used from _inner.js_, so in this example Webpack will return **b** from the generated code output.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1090,"value":"help_build_step('Inner-module tree shaking')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1093,"value":"$4b","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1098,"value":"build_step('Code Generation')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1101,"value":"md`Up until now Code Generation was format of the output for Webpack. This was something that was always in the same format, ES5. This allowed it to be readable by older browsers like Internet Explorer 11. But, that changes with Webpack 5. Now you get the chance to use either _ES5_ or _ES2015_. Default is ES2015 what is not good for Internet Explorer 11 because it doesn't have support for ES2015. So, if you want to continue the previous code format, you have to specify that you want to continue using _ES5_.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1107,"value":"build_step('Top-level await')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1110,"value":"md`Top-level await is a new functionality coming to EcmaScript soon which will allow you to make _await_ calls outside of async functions. ${html`🤗🤗`}\n\nFor example, if you would try to write code like this before, you would get an error:\n\\`\\`\\`javascript\nawait Promise.resolve(console.log('🎉'));\n// → SyntaxError: await is only valid in async function\n\n(async function() {\n await Promise.resolve(console.log('🎉'));\n // → 🎉\n}());\n\\`\\`\\`\n\nBut, now with this change, you can write code like this:\n\\`\\`\\`javascript\nawait Promise.resolve(console.log('🎉'));\n// → 🎉\n\\`\\`\\`\n\nIn addition to EcmaScript, this is a feature that will be available in Webpack 5 as well. ${html`🎉🎉`}\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1118,"value":"build_step('More changes')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1121,"value":"md`You can check more changes at the following link: https://github.com/webpack/webpack/issues/9802.\n\nSome of the most notable ones are:\n* Removing automatic Node.JS polyfills because they are unnecessary and just take a lot of space. Instead of that, Webpack is focusing on frontend-compatible modules (which are mostly the ones used for development anyway).\n* Long-term caching is improved and checking for changes in files should be better now.\n* Code splitting can now be defined by each file type.\n* Empty chunks without JS code are **not** generated anymore. This is useful especially if you are extracting CSS and JS file is now empty.\n* Node.JS 6.x is not supported anymore, so you have to use Node.JS 8.x or higher.\n* etc. ${html`😃`}\n`","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`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":979,"value":"help_build_step('Task runners')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":984,"value":"md`Task runners today are tools used to run common development tasks such as linting, building or testing. Before module bundlers overtook them, they were very popular and amongst the most popular solutions are _Gulp_ and _Grunt_.\n\nRegarding building your application, task runners can prepare and bundle our files and you can get single file and potentially quite optimized pictures as well. The problem is that task runners don't \"know\" how to read JavaScript or SASS files. They only know to do what you tell them to do, they will get the task done and that's it. Because of that, they are not popular for application building, but they can still be used for some other actions such as linting your files or running application tests. Let's look into why are Webpack and module bundlers more recommended for application building.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":988,"value":"help_build_step('Why Webpack instead?')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":991,"value":"$4c","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. other module bundlers')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":999,"value":"md`Webpack is just one of the possible solutions. Today there are more and more module bundlers and apart from Webpack, 4 more are more recognized now: Parcel, Rollup, Browserify and Brunch. All five module bundlers share the same basic functionality, but if we look a bit more in the depth, there are some differences. Let's dive more into those module bundlers and their differences.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1003,"value":"help_build_step('Introduction to 4 alternate solutions')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1006,"value":"md`_Parcel_ is a module bundler which has first appeared in 2017. Pretty young module bundler, but the one that is quickly becoming more and more popular due to putting the focus on giving developer more time for coding by handling as much as possible data out-of-the-box. On the paper, that does seem like a perfect choice, but let's first check how everything works in the practice.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1009,"value":"md`_Rollup_ is a bit older module bundler which first appeared in 2015. In comparison to Parcel, it doesn't have the luxury of running very powerful out-of-the-box build with no build, but instead of that it is focused on optimizing the bundle size with its ability to keep the files small.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1012,"value":"md`_Browserify_ is the first module bundler ever that was released in February 2011 as the first real alternative to task runners. It quickly became more and more popular due to its very powerful features. It is modular and composable with big ecosystem and each part is easily incorporated into 3rd party systems such as Gulp and Grunt, but sometimes it's even too modular because literally every feature has its own NPM package. Its big strength is a lot of plugins, really big community and very frequent updates.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1015,"value":"md`_Brunch_ is basically one more Parcel rollup also focused on speed and simplicity. It has been released pretty early (in 2011) and its configuration is simpler than in Webpack and Parcel. But, it has some downsides. There is no code splitting, handling of several assets and different file types is much worse than in Webpack and other module bundlers and some plugins are not actively updated. Good example is minimization of JavaScript with _uglify-es_ which is deprecated since summer 2018.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1019,"value":"help_build_step('Webpack vs. Parcel vs. Rollup')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"$undefined","database":"$undefined"},{"id":1022,"value":"$4d","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":"$W4e","stdlib":"1"}} 33:null