DEV Community: Mono

Multiple webpack builds with shared vendors

Dino Repac — Fri, 29 Nov 2019 13:06:08 +0000

This blog post aims to teach you (and remind me) how to setup multiple client application build procedures with shared vendors. We will be using Asp.Net Core 2 and Webpack (with DllPlugin) to build our client-side code.

Recently, we had to set up a build procedure for multiple client applications within a .NET Core MVC app. A mix of MVC and React was used to display a user interface and MobX for client-side state management. To build client-side code, we used Webpack.

Environment

Because we were using Webpack to build our code, we went on and used it to develop all of it, not just parts based on React and MobX. The requirement stated that the React part of the application has to be decoupled, and the core code (all of the UI logic and state) has to be built as a library. We didn't want React application to end up in that library; thus we used separate webpack configs

Separate webpack configs - success!

We created a common config file that was mainly used for vendor optimizations. I won't go into the optimization and caching strategies, but I encourage you to read this blog post.

Also, we created two specialized webpack configs used to build core code and React code.

// webpack.config.app.js
//...
entry: {
    app: './client/js/app.js'
},
devtool: 'inline-source-map',
output: {
    filename: '[name].js',
    path: path.resolve(__dirname, './wwwroot/dist'),
    library: 'app',
    libraryTarget: 'umd',
    umdNamedDefine: true
}
//...

and

// webpack.config.react.js
//...
entry: {
    'react-app': './client/ui/index.js'
},
output: {
    filename: '[name].js',
    path: path.resolve(__dirname, './wwwroot/dist')
}
//...

and a command to build it all (in package.json):

{
    "scripts": {
        "build": "webpack --mode <development/production> --config webpack.config.app.js --config webpack.config.react.js"
    }
}

That was super easy - npm run build and we are almost over! We just had to include scripts in the templates, and that was it!

<script asp-src-include="~/dist/modules/*.js"></script>
<script asp-src-include="~/dist/*.js"></script>

We have a problem...

Now our library app is undefined, the React application is not displaying!

We can see that two builds occurred, and that is fine, because of the two webpack configs. But, what we can also see is that multiple modules were built twice. I assumed that these modules differ and that one overwrites another. Let us test that out. We can split output files in each config and compare the output with tools like KDiff3.

We compared vendor.babel.js files in /dist/ui and /dist/js folders.

We can see that the files are not identical, meaning that one vendor file might not have everything needed for the other. This is precisely an issue in our case. So what are the possible solutions?

Split build to two different output folders and load that (probably the worst solution).
Use hash in output (we still end up with duplicate vendors).
Use shared vendors.

Solution - shared vendors

We will use DllPlugin. If you are coming from Microsoft stack, you will be (hopefully) familiar with the term DLL (Dynamic Link library).

If not, in short, DLL is a library that can be used by multiple programs simultaneously. For more information, read this.

Let us get back to Webpack DllPlugin. Essentially it is the same as described above. The plugin is splitted into two parts: DllPlugin and DllReferencePlugin.

Webpack DllPlugin:
This plugin is used in a separate webpack config exclusively to create a dll-only-bundle. It creates a manifest.json file, which is used by the DllReferencePlugin to map dependencies.

What we have to do?

Create new webpack.config.vendors.js with DllPlugin.
Define our dependencies.
Add DllReferencePlugin to our webpack.config.app.js & webpack.config.react.js.
Add build script for vendors.
Don't forget to include scripts.

We create webpack.config.vendors.js file just like any other Webpack config, but the entry point will point to our dependencies. Our dependencies are react, react-dom, mobx and mobx-react. If we do that, we will end up with something like this:

const webpack = require('webpack');
const path = require('path');

module.exports = {
    entry: [
        'react',
        'react-dom',
        'mobx',
        'mobx-react'
    ],
    output: {
        filename: 'vendors.[hash].js',
        path: path.resolve(__dirname, './wwwroot/dist/vendors'),
        library: 'vendor_lib_[hash]'
    },
    plugins: [
        new webpack.DllPlugin({
            name: 'vendor_lib_[hash]',
            path: path.resolve(__dirname, './wwwroot/dist/vendors/vendor-manifest.json')
        })
    ]
};

Now we can proceed to add DllReferencePlugin into the webpack.config.common.js. We also have to reference the manifest file.

//...
plugins: [
    //...
    new webpack.DllReferencePlugin({
        manifest: path.resolve(__dirname, './wwwroot/dist/vendor-manifest.json')
    })
]
//...

We create a separate build script, especially for vendors, and run it before the main build. The existence of vendor-manifest.json is required for running two other builds.

Running vendors build script generates dist/vendors folder with all the vendors and the manifest. When we build the rest of the code, we end up with this:

Notice the scripts with ~. These are shared scripts between vendors and our code (it may be different in your case). This was the side effect of the optimization in the webpack.config.common.js.

We have to include our scripts in the correct order and test our app.

The correct order would be:

vendors
shared scripts
specific scripts

We have this in the _Layout.cshtml at the bottom of the body:

    <script asp-src-include="~/dist/vendors/vendors.*.js"></script>
    <script asp-src-include="~/dist/vendors~**.js"></script>
    <script asp-src-include="~/dist/app.**.js"></script>
    <script asp-src-include="~/dist/react-app.**.js"></script>

And we are finally done!

Conclusion

DllPlugin allows you to separate your app and vendors. Your primary focus stays on the app you are developing, and you won't have to wait for vendors to build. You build them once, and you generally don't worry about them anymore.

While there are many blog posts around this topic, I couldn't find a single one targeting ASP.NET Core 2. Entire code used for this blog post can be found here: https://github.com/Nodios/SharedVendorsSampleApp

Space for improvements and known issues

If we try to add vendor optimization to the webpack.config.vendors.js the build messes up vendor-manifest.json. I am yet to find a reason why that happens. If you have an answer, please contact me.

As you can see, incorporating scripts into the views is a tedious job. You have to be very careful with the ord
er of the scripts; otherwise, your code won't work. I used HtmlWebpackPlugin to inject scrips in the view, but the problem is when you have multiple layouts and areas things tend to go out of hand - especially with shared scripts. If you have a solution to this, feel free to contact me as well.

This article is originally published on Mono.

Supercharge your colors with the PostCSS color() function

Mihael Tomić — Fri, 25 Oct 2019 09:17:20 +0000

Colors provide an atmosphere crucial to our design. They communicate design intentions and send a message to the people.

In this article, we will take a look how using plugins for PostCSS can help us in defining a color theme for our website and how to use colors across our project.

What is the color function?

CSS color function is a W3C draft proposed by Tab Atkins which will help us to modify base color with the assistance of color-adjusters like hue, saturation, lightness, tint, opacity, etc. If you are familiar with a graphic software like Photoshop, Affinity Photo or any similar software and its adjustments tools, this will sound familiar.

In our case we will use a tool called postcss-color-function - a plugin to transform W3C CSS color function to more compatible CSS.

What is so wonderful about this? After browsers start to fully support specification and implement it, we can kick out the plugins and start using browser native CSS parsing for color function.

Defining our color theme

To create a functional color theme, we have to define the right colors for our project. The initial setup is important since it will help us create a starting point for simple color usage across all the (Post)CSS files.

We will use a color naming tool from Colblindor to assign a name to our hex colors. For this demo, we will use color palette created from the Star Wars™ The Last Jedi poster.

// Detect dark theme var iframe = document.getElementById('tweet-886335965744082944-986'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=886335965744082944&theme=dark" }

Now we will define variables* using the postcss-simple-vars plugin which gives us the ability to write and use JS-like variables we're familiar from Sass.

/** Brand colors **/
$cinnabar: #DF3D2F;
$seal-brown: #080202;

/** Theme colors **/
$color-primary: $cinnabar;
$color-secondary: $seal-brown;

We're finished with our setup. From now on - we will use only theme colors in our project.

*You can also use CSS variables which are W3C CR and not fully supported by all browsers. In our workflow we use PostCSS, and I'll use it in the following examples.

Practical use cases

There's a lot of stuff we can do with color functions, and I'll cover some of them in following examples. I won't include all the adjusters; you can find them in documentation and explore in detail by yourself.

The color function accepts many color spaces - you can use RGB, HSL/hwb, browser colors and HEX values and manipulate them.

With the right combination of PostCSS plugins (for nesting, variables and color function) we can quickly create consistent and easily maintainable pseudo states for buttons in our project.

Button pseudo state

Our HTML code:

<button type="submit">Join me!</button>

combined with our PostCSS...

button {
  ...
  box-shadow: 1px 1px 3px color(black a(0.2));
  background-color: $color-primary;

  &:hover,
  &:active {
    background-color: color($color-primary lightness(+5%));
    box-shadow: 0px 3px 10px color(black a(0.4));
  }

  &:focus {
    background-color: color(black blackness(+10%));
  }
}

...gives us a great level of control over the button element. We can change our base colors as many times as we want without thinking about what will happen with the pseudo states.

As you can see from compiled CSS, all values are readable for all browsers.

button {
  box-shadow: 1px 1px 3px rgba(0, 0, 0, 0.2);
  background-color: #DF3D2F;
}

button:hover,
  button:active {
  background-color: rgb(226, 83, 70);
  box-shadow: 0px 3px 10px rgba(0, 0, 0, 0.4);
}

button:focus {
  background-color: rgb(196, 58, 46);
}

View functional example on CodePen:

Using color function with postcss-inline-svg

One of the tools we use in our everyday projects is postcss-inline-svg - "a plugin to inline SVG and customize its styles". I find the combination of these two plugins handy. Since CodePen does not support inline-svg plugin, I'll try to reproduce it through images and code examples.

Source PostCSS

.icon--empire {
    background-image: svg-load(../images/icon-delete.svg, fill: color($color-secondary lightness(+30%)));

  &:hover {
      background-image: svg-load(../images/icon-delete.svg, fill=$color-primary);
  }
}

Compiled CSS

.icon--empire {
    background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg fill='%23030303' height='24' viewBox='0 0 24 24' width='24' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='M6 19c0 1.1.9 2 2 2h8c1.1 0 2-.9 2-2V7H6v12zM19 4h-3.5l-1-1h-5l-1 1H5v2h14V4z'/%3E%3Cpath d='M0 0h24v24H0z' fill='none'/%3E%3C/svg%3E");

  &:hover {
      background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg fill='%23DF3D2F' height='24' viewBox='0 0 24 24' width='24' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='M6 19c0 1.1.9 2 2 2h8c1.1 0 2-.9 2-2V7H6v12zM19 4h-3.5l-1-1h-5l-1 1H5v2h14V4z'/%3E%3Cpath d='M0 0h24v24H0z' fill='none'/%3E%3C/svg%3E");

  }
}

PostCSS would produce an SVG icon in base64 after compiling.

The good

The good thing about this approach is that you can generate icons easily through CSS and have color control for fill and stroke. All icons are in one place and can be used across as utils.

The bad

There's no way (as far as I know) to add CSS classes and animate SVG through CSS paths or other elements in SVG. Also, there's no SVG code in our markup.

To wrap it up

The color() function is a powerful tool and can be used in many creative ways. After browsers start to support it fully, we will see its full potential. For now, we have tools to help us unlock that potential and use its benefits today.

This one is an old article I wrote for Mono, but I feel it also belongs here, on Dev.to community.