The Webpack configuration of Vue Storefront 1
The Webpack configuration of Vue Storefront 1 is a bit more fancy though. First of all, their
package.json scripts don't run a Webpack server instance right away, but instead use
ts-node (so a Node client that supports TypeScript) to kickstart a complexer Webpack configuration with many features on board.
One of the benefits here is that you can use TypeScript to make definitions for Webpack. You wouldn't able (?) to use TypeScript directly in a Webpack configuration because you need Webpack to translate that TypeScript first. Instead, the VSF CLI scripts kick off part of the application, that then determines various things on the fly: The theme name, language files, the Webpack configuration itself for either production or development.
Compilation times in a default Vue Storefront 1 environment
However, this approach increases loading times, which leads into developers being unhappy. When you type in
yarn dev in a Vue Storefront environment, you can easily expect a compilation time of a minute or more. In my case, I'm often waiting for 40 to 50 seconds (Ubuntu, SSD drive, plenty of RAM, no apps open).
Worse, once the development server is running and you modify some component (
Home.vue), you'll need to wait for another 4-6 seconds before this incremental compilation is loading as well.
The reason is SSR
So I dived into this to see if we could improve things. And it surprised to me to find out that actually the development environment was still running production code: The approach Vue Storefront took was to kickstart their own Express server, use the Webpack API within it and load all that needed to be loaded.
However, on top of this, the client code would be compiled into the
dist/ folder (which basically boils down to the code being the real-life production code that normally would be uploaded to a production environment, aka
yarn build) which was then rendered by yet another part of the same client. This sounds complex, it is, but it holds one secret ingredient: Thanks to this approach, the development server is able to produce static HTML pages that include the actual HTML that would normally be rendered dynamically in the browser: Server Side Rendering (SSR) within a local development environment.
I don't want SSR in development
Definitely, I would not recommend going live with a Vue Storefront app without having tested SSR properly. And the default configuration allows me to test this properly. But at the cost of a slow compilation time. The reality is also that an average frontend developer is actually more busy with creating Vue components, writing SCSS, extending upon Vuex, then testing SSR. On a regular day, you don't want SSR to be enabled and then slow down your environment.
So I sat down and started to write a Webpack configuration from scratch, while still borrowing the necessary elements from the original Vue Storefront app (aliases, rules): github.com/yireo-training/vsf1-local-webpack - an open source project, free to use and open to contribute.
Loading times with my custom Webpack configuration
The loading times are awesome. The initial compilation time with the default Webpack is about 60 seconds. For me, my custom Webpack requires 30 seconds. Even better, I make use of the
hard-source-webpack-plugin plugin which maintains a cache of compiled files. Killing
yarn dev and restarting it again takes less than 5 seconds.
Also, while the development server is running, an incremental build (
yarn build) takes only 1 or 2 seconds. It is speeding things up tremenduously for me.
Setting things up
The README of the GitHub project explains how to go through the various steps. The setup requires the Webpack configuration and a
public/index.html to be copied to your own Vue Storefront app. Plus, it requires you to copy images from your themes
assets folder to
public - an issue that is hopefully improved in the future.
Next, the Webpack plugins
uglifyjs-webpack-plugin need to be installed. Plus, there is a specific bug in
dayjs (something with a TypeScript definition file) that requires a specific downgrade.
Once you follow the procedure, you will add a new command
happydev to your Node scripts and you are good to go with
Let me know if this works for you too. And it would be happy to see some improvements come in via GitHub Pull Requests.