Preface

Next.js is full of many magical stuffs behind that does magical things without you realizing it. The SSR (Server Side Rendering) is already something magical, combined with capability to do SSG (Static Site Generation). There lots of magical stuff happens that I may have not discovered, yet. And that's a good thing! Since I can explore more and flood my mind with fresh ideas when I discover new stuffs.

Problem with SSR and External Scripts

Back to the issue, I was trying to actually just embed highlight.js library without using CDN. I know this isn't a pretty good idea since it gonna add more bundle size, but eh, I think it's pretty tolerable for now. Gonna worry about that later, ehe.

Embedding highlight.js (imma abbreviate it to "hljs" onwards) or actually having references to the library is required for me to use syntax highlighting in Quill.js. It wasn't really much of a hassle when I preload hljs before actually using it. Next.js being server side rendered means that there's possibilities that the component that uses hljs going to load first before hljs CDN script got fetched and loaded. It creates an annoying error where Quill.js won't load properly (it throws error). Single refresh can fix this, but that's not a pretty good UX.

And so, I searched up on how to actually embed the library reference into the window object of the browser. Basically when you fetch the CDN script, the reference will go to the attributes of the BOM. In case of hljs, it will be placed under "window.hljs". Other scripts that depend on this library can now access this library using said reference.

But the problem persists. There could be moment where the library hasn't finished loaded yet, and the React component already want to use the library. Without proper handling, it will throw error and the page will return error 500. So I came with 2 ideas

Actually waits until the library finished loading.
Include the library in bundle script.

The first idea didn't really do something because I might've done it wrong, but I think it's the best approach so I can use CDN instead of bundle scripts. And so I went with the second idea.

webpack's ProvidePlugin

This is where webpack actually comes handy. After looking through several issue threads in Github, I found that using ProvidePlugin in webpack config is one of viable way. How I perceive ProvidePlugin works is by replacing the reference to a certain library with the npm package we set in the config.

Let's say that you want to use jQuery without actually importing jQuery in every component you have. You can do this by loading external script, but that's just potential for another problem. So, you can use ProvidePlugin to implicitly import the library and make a certain reference to point into the imported library.

webpack.ProvidePlugin({
  "window.$" : "jQuery",
  "$" : "jQuery"
});

This will set webpack to point any reference that starts with "window.$" to jQuery library. The same thing also with "$" reference. You can think it as global variable that already set, so you don't need to worry anything.

The downside is, this is not really a global variable. You can't call the reference to "window.$" in the browser because this plugin doesn't really load the said library into the reference pointed. It just replace any matching reference with the npm module that's going to be loaded by webpack. But at least, this thing works and I can stop worrying about hljs not loading.

If you want to go with adding global variable, you can go for Shimming method for webpack or by using expose-loader for webpack. I still need to read about this more, but I think I have idea on the good use case.

Next.js webpack Configuration

Now, how to use this with Next.js?

Custom webpack configuration already has a tutorial page in the official documentation. You start with creating next.config.js file at the root directory of your Next.js project. Just make sure it's in the same directory with package.json.

Now just write this inside the newly created file.

module.exports = {
  webpack: (config, { webpack }) => {
    config.plugins.push(
      new webpack.ProvidePlugin({
        'window.hljs': 'highlight.js',
        hljs: 'highlight.js',
      })
    );
    return config;
  },
};

And that's it! You now have every reference to "window.hljs" and "hljs" pointed to "highlight.js" module. This should apply to any other modules that can work in browser and has default export (actually correct me if i'm wrong here).

Summary

I do believe that there's better approach when working with Webpack. I need to explore this more in my next iterations.

As I've deployed the changes, I realized that my codes aren't being highlighted because I forgot to initialize hljs.

*sigh....* Another hotfix, but imma just go for later.

Until then, See ya!

Loading...

There will be awesome contents here

Log-0x13 - Next.js webpack ProvidePlugins