Dzulqarnain Nasir

  • November 11, 2020

    Real-time web applications with gRPC - Part 1

    In this series, I’ll be collaborating with my colleague, Valdis Iljuconoks, on the topic of real-time data distribution using gRPC. If you haven’t done so already, head over to Valdis’ blog for a multi-part series on “Building Real-time Public Transport Tracking System on Azure” for details on setting up the Azure infrastructure for this project. This post focuses on the client distribution system.

    Let’s get started.

    Read more »
  • April 01, 2020

    Migrating from WebpackDevMiddleware to SpaServices.Extensions

    Upgrading to .Net Core 3.x resulted in some breaking changes for my front-end development process, in particular the Hot Module Reloading (HMR) feature that I use in all my projects.

    If you use the WebpackDevMiddleware, it’s likely you would have seen this message pop up after upgrading to .Net Core 3.

    Sad day

    So, what do we do now?

    Read more »
  • September 16, 2019

    Getting Storybook to work with Vuetify 2.0

    This is just a short post regarding how I got Storybook to play nicely with Vuetify after upgrading to Vuetify 2.0.

    As most of you already know, Vuetify 2.0 recently came out. That’s awesome, but it also came with a few breaking changes, the primary of which is their move towards making Vuetify a Vue plugin, which had to be bootstrapped to the primary Vue instance.

    This is fine and all, except it broke my Storybook build.

    Sad day

    Read more »
  • May 20, 2019

    Azure Functions + Node.js + TypeScript + Webpack

    I’m a big TypeScript fan. If my blog posts and GitHub projects haven’t already made that clear, I’m now putting that on record.

    So when I found out that the latest azure-functions-core-tools now comes with the ability to create a Functions app in TypeScript out of the box, I got excited.

    In this post, I’d like to share my experience setting up an Azure Functions App project for Node.js in TypeScript, with Webpack for generating the app bundles.

    Read more »
  • January 14, 2019

    Webpack-ing static content for TypeScript

    Here’s a quick one.

    I’ve recently started cleaning up the code for one of my projects, and one of the things I did was introducing the file-loader plugin, and converting static content references throughout my codebase.

    It was a pretty straightforward process for image URLs within my Vue files, but then I also have code that switches out the background image of elements based on specific conditions. This requires the static content URL to be imported into the code that handles the logic.

    For example:

    // component class
    get centerOverlayStyle() {
        let backgroundImage = null;
        if (this.inputMode === MapInputMode.PICKUP) backgroundImage = 'url(/public/static/pickup-icon.svg)';
        if (this.inputMode === MapInputMode.DROPOFF) backgroundImage = 'url(/public/static/dropoff-icon.svg)';
        return { backgroundImage };

    In order for me to use the image files emitted by file-loader, I need to replace the image paths with the ones generated by the plugin.

    According to the documentation, I can simply import the image file into my code, and assign it to a local variable, and use it whenever I need reference to the image URL anywhere in my code. file-loader would resolve the path, allowing my code to point to the correct URL.

    import pickupIcon from '@/static/pickup-icon.svg';
    import dropoffIcon from '@/static/dropoff-icon.svg';
    // component class
    get centerOverlayStyle() {
        let backgroundImage = null;
        if (this.inputMode === MapInputMode.PICKUP) backgroundImage = `url(${pickupIcon})`;
        if (this.inputMode === MapInputMode.DROPOFF) backgroundImage = `url(${dropoffIcon})`;
        return { backgroundImage };

    Unfortunately, while this works for regular JavaScript, TypeScript sees this as a problem.

    Cannot find module '@/static/pickup-icon.svg'.
    Cannot find module '@/static/dropoff-icon.svg'.

    TypeScript assumes that everything we import are modules, and if it cannot determine this to be the case, it will log an error. The definition of a module can either be determined by the imported TypeScript (.ts/.tsx) file, or by a type declaration file (.d.ts) that the code depends on. [Reference]

    So, the solution is quite simple. We just have to tell TypeScript about our image files by adding a type declaration file (d.ts.), and declare the image files we’re using in our project as a module.

    // images.d.ts
    declare module '*.svg';
    // duplicate for other image file extensions

    Et voilà. Problem solved.