I'm using Webpack to compile my JavaScript bundles and am very happy with it. I'm also using it to compile my LESS files to CSS via the ExtractTextPlugin which is also working really well. I've started looking into the end size of the bundle and it's makeup and have found something I'd like to fix:
less-loader is taking up 9.9% of the bundle size. That seems a lot in and of itself, however what really strikes me is that I don't think I really need it in the bundle at all. I've already extracted the CSS as it's own file and don't do any require('./component.less') anywhere in my JavaScript modules.
Is there a way of asking webpack to exclude it that won't ruin the less -> css compilation?
With ExtractTextPlugin, your built style sources do not become a part of the resulting JS bundle. They'll rest in the output directory and unless you explicitly reference the files, they will not be included in the document.
I'm assuming the tool for analysis that you're using includes all outputs of the compilation as being part of "the bundle".
It seems an error in webpack-visualizer.
Open node_modules/less-loader -> index.js, take any string from it (I use loaderUtils.parseQuery) and search for it in your bundle.
I found nothing, so seems loader not included.
Related
I'm using Webpack in a fairly simple, straightforward way that bundles together a few JS and TS files into one bundle, and it works well on my site.
However, I want to split the current bundle into smaller bundles, as I get both a warning when I build the bundle due to it's size, and I get warnings running Lighthouse audits in browser that I should reduce the file size of my bundle.js file.
The simplest solution in my mind is to split my current bundle into 4 parts, i.e. bundle1.min.js, bundle2.min.js, etc... Then I just serve the bundles consecutively.
The problem is splitting and serving my bundle this way is breaking other JS on my page. For example a function defined in bundle1 and called in a different JS file no longer works, unless I remove all the other bundle.js files. It seems that only the most recently loaded bundle file works.
Is there a better approach to get smaller bundles, and make sure that all bundles work correctly?
Route-based code splitting is quite popular because each page/route usually has a small subset of components on it.
The guide can be found here (for React)
A little embarrassed, looks like this was just a scoping issue with a dependency in one bundle breaking code in another by being absent. Reorganizing my bundles so dependencies are present where needed. Ai ya.
I'm using vscode to build a larger TypeScript application. Let's say one day I decide to use absolute paths for module imports, because I want to be more directory structure agnostic. So I add the appropriate configuration, also configure vscode to prefer non-relative imports.
But I end up with lots of already existing imports in every file, which is a huge work to manually fix. What I can do file by file is delete all imports, and use the automatic imports for that file. Still, I have to do this for every piece of source file, which is still a nightmare.
Is anyone aware of any kinds of built-in or extension tooling which can help in situation like this? What I could image is something that resets all the imports in every file and re-imports automatically everything, based on the new settings.
When using Webpack, it makes complete sense to use it to package your client-side JS. But what is the purpose of using it to compile your SASS and load your CSS into your page? In the end it appears that you need to use another Webpack plugin (ExtractTextWebpackPlugin) in order to pull out the CSS when you are ready to deploy to production.
It seems like you are going full circle here. Before Webpack you load your CSS in the <head> using a <link> tag like normal. Now using Webpack you load it via your JS bundle. And now for production you use a Webpack plugin to put it right back into the <head> tag again. So what's the point?
There are already dozens of tools and methods for compiling your CSS and live-reloading it in the page without Webpack. What is the advantage of using Webpack for your SASS/LESS/CSS to begin with?
tl;dr I don't think you are looking at Webpack in its' full capacity. If you are hung up on just working with CSS preprocessors than just stick with their stand alone compliers and move on.
Webpack only reads JavaScript, so that's where Loaders come into play. When you want to start working with other file types you'll need to configure loaders to pull out the specific code and have it run the necessary tasks. It's no different than Gulp's Pipelines or Grunt's Configuration blocks.
The point of loading CSS (or any preprocessor) into Webpack is because you want to have a full fledge task runner that handles bundling your code, live-reloading, image optimization, environment variables, code optimizations, HTML templates, among everything else that's possible. You wouldn't just use Webpack as a standalone CSS Preprocessor that's not the objective.
I've recently been thrown in to clean up a project which has like 45-50 individual .js javascript files. I wonder what the best approach would be to decrease the loading size of them all. Just concatenate all files into one with npm or gulp? Install some module loader? webpack?
If you're already concatenating, minifying, and uglifying and you don't want all the files to be loaded on all the pages due to a monolithic bundle, you might be looking for something like Webpack's Commons Chunk Plugin.
This plugin walks down the tree of dependencies for each endpoint defined in your Webpack.config file and determines which modules are required across all pages. It then breaks the code into two bundles, a "common" bundle containing the modules that every page requires, which you must load with a script tag on each page:
<script src="commons.js" charset="utf-8"></script>
And an endpoint bundle for each individual page that you reference normally in a script tag placed after the commons script tag:
<script src="specificpage.bundle.js" charset="utf-8"></script>
The result is that an individual page will not have to load modules that will only ever be used on other pages.
Again, this is a Webpack plugin. I don't know if this functionality is available as a Gulp plugin, because it must have knowledge of all endpoints in order to determine which dependencies are common to them all.
I redirect you to the very good https://github.com/thedaviddias/Front-End-Checklist
In particular the following advises:
JavaScript Inline: High You don't have any JavaScript code inline
(mixed with your HTML code).
Concatenation: High JavaScript files
are concatenated.
Minification: High JavaScript files are minified (you can add the .min suffix).
You can accomplish this with a package manager such as gulp, grunt or webpack (for the most famous ones). You just need to choose what you prefer to use.
If you consider webpack, You can start with my very simple (but understanding) starter: https://github.com/dfa1234/snippets-starter
There's no much thing that you can do, basically is:
Concatenation - https://www.npmjs.com/package/gulp-concat
Minification - https://www.npmjs.com/package/gulp-minify
Instead of creating all those scripts, you can get something to re-use on yeoman, f.e. the Fountain, so it will reduce a lot of time just typing procedural code for doing the concatenation/minification.
Also if you can use some lazy load (like RequireJS or some frameworks have support to lazy load the module, like Angular) that will improve the performance of your aplication
EDIT:
If you want even more performance, you can install some compression tool in your server, for example this one for NodeJS https://www.npmjs.com/package/compression
I'm my personal opinion, if you have time, the best approach would be to read and understand the purpose of the project. Then plan a proper refactor. You are not fixing anything with concatenating, this is just a deployment step.
You should analyze which technologies are being used and if you want to maintain this code, in the long run, make a proper refactor into a much more modern stack, maybe you can take a seed project with ES6, webpack, Babel... and create a proper repository well maintained with proper modularity and dependencies resolution.
Once you have that, decreasing the load its just about adding proper tools in build time (babel, webpack, etc).
You would like to add some unit tests and continue working properly :)
I need your help with website project I'm working on. My project consits of 7 html documents, 3 stylesheets, 8 .js (including jquery.min.js and some jquery plugins) and some pictures. I want to bundle and minify it as much as it is possible (it would be good to get only 1 css and 1 js file or maybe 1 js, which contains styles inside).
For clarity - now, when I have all dependencies in html - everything is working properly. But I'm not sure how to set all module.exports and requires. Could you tell me how to do it step-by-step in a proper way?
Many thanks in advance.
PS. I write in ES5, so I don't use Babel.
You can do the following to make your codebase a bit more tidy.
Manually group the content of your relevant js files into one and export it as a nodejs module by using module.exports = module_name on the top of your merged js script (Repeat as needed for any jscripts in your project).
Then include the exported module in your main node file and include its main functionality using var modulesfile = require(./module_name); Please note directory paths while importing your js modules.
You can also run a minifier like minifyjs to make your js files size even smaller if they need to be called multiple times from a url. Nodejs installation and usage for minifyjs can be found here.
You can also call other css from within existing ones by using the
#import url("./css/filename.css"); Just verify proper css directory paths first.
In case you also want to use browserify for node there is a full guide in the npm website.
Another good and simple solution is to move all of your codebase in a visual studio web project. From there you can do pretty much what you want, organize your scripts and css files (/Scripts and /Content directories) in bundled configuration files etc.
NOTE: All your code has to be migrated to an asp .NET project to use this approach (as per Microsoft doc) properly.