Despite the fact that I’ve been doing this whole front-end development thing for over a decade now, I still get caught up on silly things. Mostly build-related things trip me up.
In a project using Webpack for the bundler, I needed to copy a folder from a node_modules directory and include the files in my bundle (don’t ask).
The first thing I did was this:
new CopyWebpackPlugin({ patterns: [ { from: 'node\_modules/@ia/qce/dist', to: 'content/qce' }, ]}), Now, the problem here is that the copy-webpack-plugin will copy the entire path to the file. So, inside of my content/qce directory I had node_modules/@ia/qce/dist folders (the entire path). It will recreate the entire folder structure from the from value instead of just taking the contents (like we want).
I really dislike the CSS-In-JS trend. Nothing against anyone who is a fan, but writing CSS inside of Javascript doesn’t feel natural and honestly, it’s just an unnecessary abstraction. I understand why it became a thing, but the problems CSS-In-JS promises to solve have already been solved thanks to CSS Modules and Shadow DOM.
As usual, the front-end development community are focused on tooling and not on the end-user experience. Numerous benchmarks have proven CSS-In-JS can introduce performance issues into your application.
Recently I updated to the latest version at the time of writing this post 5.0.2 of the file-loader plugin for Webpack. I use this for dealing with some image files in my project amongst other things.
To my surprise after updating, I noticed my SVG images had all broken without explanation. It turns out a recent fix to the esModule option had enabled a default value of true for esModule which generates Javascript modules that use ES syntax.
At the time of writing this post, TypeScript 3.7 is in beta. Eventually, this post will become irrelevant. But, for the moment if you are trying to get TypeScript 3.7 Beta or any of the RC builds working with Webpack and ts-loader you might have encountered a bunch of red text in your console.
In my case, I had target: "esnext" set in my tsconfig.json file which the ts-loader plugin should read and set the appropriate settings. And yet, TypeScript 3.7 Beta was not working despite making sure everything was up to date.
Now that Webpack 4 is out, it supports a plethora of new things and features, one of those is the native handling of JSON. In theory, this is great, but in a particular application I am working with which is JSON heavy, the native JSON loading caused a trove of errors.
Obligatory photo of some code
Fortunately, inside of your module.rules section of webpack.config.js you can disable the native JSON loader and use the json-loader package which seems to be more reliable at present.
I have migrated over to Webpack 4 for Built With Aurelia and I am using the fantastic Aurelia Store plugin.
During development, everything worked fine, but when I would do a production build the state management aspect would fall apart, complaining about something to do with the function that notifies Redux Dev Tools about the change (what the action name and state value was).
It took a lot of trial and error (a solid day) for me to work out what was going on.
Surprisingly, whilst determining the best way to polyfill promises in a Webpack build and using Bluebird I came across such mixed results.
A lot of the posts out there don’t mention Bluebird at all, opting for es6-promise when it has been proven Bluebird has such great performance, it’s even faster than native promises in some browsers.
A lot of the results I found were from 2015 and a couple in 2016. As you know, front-end development moves rapidly and 2015 is 100 years in front-end land.