DEV Community: Lev Eidelman Nagar

Joining the (Module) Federation

Lev Eidelman Nagar — Wed, 28 Feb 2024 18:00:00 +0000

Introduction

Module federation is a way of loading remote modules in runtime (as opposed to during the build process) and is a common way of implementing micro-frontends in modern web applications which use webpack.

In this guide I will show you how you can load any remote module at runtime.

I assume that you have at least passing familiarity with the basics of webpack and module federation.

If this is a new topic for you I highly recommend reading the official webpack documentation and visiting module-federation.io/ for more information.

When You Can't Commit

Most module federation examples and tutorials out there will have you configure module federation for your host application like so:



// webpack.config.js

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        app1: 'app1@http://localhost:3001/remoteEntry.js',
        // ...additional remotes
      },
    }),
  ],
};

While this will work locally, it does not take into account the following:

Different environments(e.g. staging, production)
Needing to load an arbitrary remote from an unknown(at least during build time) URL

Although the first can be solved by using external-remotes-plugin, handling arbitrary remotes is less obvious.

I should also note that configuring the remotes this way means that all remotes will be loaded when the page initially starts. This means the user will incur the cost of having to load additional Javascript files even if they never use any of it.

A Little Helper Goes a Long Way

I created a small utility function that accepts the URL of the remote module or a promise that resolves to it, loads the remote script by creating a new DOM <script> element, initializes the module and returns it.



type RemoteAppSettings = {
  scope: string;
  module: string;
};

/**
 * Loads a remote application module
 * See [Dynamic Remote Containers](https://webpack.js.org/concepts/module-federation/#dynamic-remote-containers)
 * for more information on how this works
 * @param url Remote app URL or function that resolved to a URL
 * @param app Remote app settings
 * @returns Remote module
 */
export function loadRemoteApp(
  url: string | (() => Promise<string>),
  app: RemoteAppSettings
) {
  const { scope, module } = app;

  return (): Promise<{ default: ComponentType<any> }> =>
    new Promise(async (resolve, reject) => {
      const element = document.createElement('script');

      let resolvedUrl: string;

      if (typeof url === 'string') {
        resolvedUrl = url;
      } else {
        resolvedUrl = await url();
      }

      element.src = resolvedUrl;
      element.type = 'text/javascript';
      element.async = true;

      element.onload = async () => {
        // Initializes the share scope.
        const container = window[scope];
        // Initialize the container, it may provide shared modules
        await container.init(__webpack_share_scopes__.default);
        const factory = await window[scope].get(module);
        const Module = factory();

        resolve(Module);
      };

      element.onerror = err => {
        reject(
          new Error(
            `Failed to initialize remote Application\nURL: ${url}\nScope: ${scope}\nModule: ${module}`,
            { cause: err }
          )
        );
      };

      document.head.appendChild(element);
    });
}

Now we can remove all pre-configured remotes from our webpack.config.js:



// webpack.config.js

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {},
    }),
  ],
};

And in our React application we can use this helper to load a remote component and render it with lazy and <Suspense> like this:



import { getRemoteUrl, loadRemoteApp } from 'common/utils/moduleFederation';
import ErrorBoundary from 'components/ErrorBoundary';
import { Loader } from 'connected-components/Loader/Loader';
import { ComponentType, Suspense, lazy } from 'react';
import { RemoteComponentProps } from 'types/micro-frontends';

const RemotApp = lazy<ComponentType<RemoteComponentProps>>(
  loadRemoteApp(
    // Call the backend to get the remote URL
    getRemoteUrl('component-name'),
    {
      scope: 'remote',
      module: './App'
    }
  )
);

export function RemoteComponent() {
  return (
    <ErrorBoundary>
      <Suspense fallback={<Loader />}>
        <RemoteApp/>
      </Suspense>
    </ErrorBoundary>
  );
}

Now the remote module will not be loaded until required and we can use any valid remote URL.

Handling Broken Images in React

Lev Eidelman Nagar — Mon, 25 Sep 2023 12:17:12 +0000

Often when linking to an external resource we run the risk of that resource being unavailable. In the case of an image we will get the dreaded broken image icon:

Lucky for us as web developers, the <img> tag accepts an onerror event which we can use to handle a missing or otherwise broken image.

This is how we can leverage this in React with Typescript:

import { HTMLProps, ReactNode, useState } from "react"

/**
 * We extend `<img>`'s properties as we want our 
 * component to act as a drop-in replacement for it
 */
type ImgProps = HTMLProps<HTMLImageElement> & {
   /**
   * Optional fallback to render in place of a missing image
   * @default null
   */
  fallback?:  ReactNode
}

export function Img(props: ImgProps) {
  const { fallback = null } = props;

  /**
   * is our image broken?
   */
  const [isBroken, setIsBroken] = useState(false);

  function handleError() {
    setIsBroken(true)
  }

  if (isBroken) {
    return fallback;
  }

  return <img onError={handleError} {...props} />
}

Now, it is simply a matter of replacing the default <img> tag with our custom <Img> component:

import { Img } from './Img'

function App() {

  return (
    <>
      {/* Regular old image */}
      <img src='https://nosuchsite/nosuchimage.png' />

      <hr/>

      {/* Our custom image component */}
      <Img src='https://nosuchsite/nosuchimage.png' fallback={<div>🚧 image not found 🚧</div>} />
    </>
  )
}

export default App

Which will result in:

I hope you found this post to be helpful!

The New Kids on the Block

Lev Eidelman Nagar — Thu, 10 Nov 2022 09:09:29 +0000

As I have written before my preferred code editor is Sublime Text. I chose it over the more popular VSCode for its' speed and performance (and a bit out of being a cranky old programmer if we're being honest).

However, some recent arrivals on the scene made me reconsider my choice. While they're not all there yet in terms of maturity and ecosystem I've been very impressed with all of them and can't wait to see what these projects evolve into in the future.

Also, I think the many similar choices these projects made are noteworthy. But, I'm getting a bit ahead of myself, so without further ado, these are the new kids on the block:

Zed

Like the legendary phoenix, Zed rose from the ashes of another revolutionary code editor - Atom.
Zed's team is comprised of Github and Microsoft alumni who've previously worked on Atom and VSCode, so these folks know what they're doing.

Like Atom in its' day, Zed focuses on collaboration. It implements the LSP protocol for code completion and intellisense and uses Treesitter for syntax highlighting.

Unlike Atom however, Zed is written in Rust so it is practically guaranteed to be fast and efficient.

It has a built in terminal emulator based on Alacritty.

Currently it is mostly geared toward developing in Rust, as it is used to write Zed itself, but a small handful of other languages is supported as well.

Out of the three editors on this list Zed is the most like sublime text in terms of look and feel. It's minimalist, clean and fast. With additional functionality just a keystroke away if you need it.

Zed is currently only available on MacOS.

Lapce

If Zed is the spiritual successor of Sublime Text, Lapce (pronounced like Lapse) feels like bizarro VSCode but in a good way. Everything is at once familiar and different.

A bit more mature than Zed, it is also written in Rust and implements LSP, has a built in terminal and even has basic git support.

It also has the beginnings of a plugin ecosystem. Interestingly, a plugin can be written in any language that compiles to WASI.

Lapce looks incredibly advanced for a project that's in pre-alpha and I am curious to see where it goes next.

Lastly, I'd like to show you something a little different:

Helix

Unlike the other editor on this list, Helix is a text based code editor written in Rust and is more of an alternative to Vim or Neovim than VSCode.

Like the other editors here it implements LSP and uses Treesitter and is the only one on this list so far that implements DAP for debugging.

All in all it feels like a more modern version of Neovim with many built-in features NVim delegates to plugins.

Although text-based editors aren't my thing I was very impressed with how efficient and ergonomic Helix feels.

Afterthoughts

The future looks bright. In the coming years we will have a greater variety of tools to choose from, each focusing on different aspects and preferences, while delivering many of the same capabilities.
Rust is here to stay and seems to be the go-to language for anyone working projects where performance is critical.
So is VSCode, or at least LSP and DAP as none of these projects bothered with developing their own auto completion engine or debugging protocol.

I hope you've enjoyed this brief overview and I hope you will give these editor a try.

Migrating from VS Code to Sublime Text in 2022

Lev Eidelman Nagar — Wed, 16 Feb 2022 18:59:35 +0000

VSCode needs no introduction as it is probably the most popular IDE/code editor at the moment. It has many useful built-in features as well as tons of 3rd party extensions in it's marketplace.
It is maintained and regularly updated by Microsoft and has a vibrant community of users and developers.

However VSCode has a dark side to it... No, I'm not talking about Microsoft harvesting your data for their nefarious purposes (although that's certainly an issue in my opinion). What I am referring to is VSCode's comparatively sluggish performance and the strain it puts on the computer's resources.

Although Microsoft did an amazing job of optimizing and squeezing every last bit of performance out of Electron, there's no getting away from the fact that VSCode will always be at a disadvantage compared to other code editors written in more low-level languages.

Also, and this is obviously more of a personal preference, I find VS Code's design and layout to be a bit too "busy" for my tastes as I prefer a more clean and minimalist UI with less distractions.

Fortunately, as you'll soon see, there are alternatives. But first a couple of small caveats:

VSCode is great! No, really. It's not my intention to bash it or any other editor/IDE for that matter.
The fact that it's free and mostly open source should be celebrated.
Beside the above mentioned reasons, using VSCode is also the path of least resistance. Speaking from experience, it is super easy to set up and be productive with in no time. This is especially important for novices as almost any other tool will require you to put in some extra effort into setting it up.
However, if you're the type of person who enjoys maintaining and fiddling with your tools this guide might just be for you.
I am a full stack web developer working mostly with Node.js, React and Typescript. This setup is what works best for me, but may not work as well/at all for you. Having said that, many of these ideas and concepts will translate well into other languages and paradigms.

With these out of the way, let's move on and see why I chose to use Sublime Text and how I set it up as a powerful alternative to VSCode.

Sublime Text

Sublime is a closed source code editor written in C++. It also has a python API which can be used to extend it with additional functionality.

It's not free software, but you can "evaluate" it indefinitely if you don't mind the occasional popup window.
However, if you enjoy using it and can afford it, I highly recommend to buy a license and support the developers.

Although, not as popular as VSCode it has a devoted following and plenty of packages on it's marketplace called package control

In my experience, any sufficiently popular extension for VSCode will sooner or later be ported to Sublime (and vice versa).

Sublime is a fast and capable code editor, able to handle large files with ease, but it is still "just" a text editor. Let's see how we can turn it into more of an IDE.

Intellisense and Diagnostics

Luckily for us, the same autocompletion engine that powers VS Code is available to us in sublime through the LSP family of plugins.
To make a long story short, the Language Server Protocol is a protocol that standardizes the way code editors communicate with compilers through language servers.
Install the language servers relevant for your setup (for me it's lsp-typescript, lsp-css, lsp-json and a lsp-tailwindcss) and you'll be rewarded with powerful autocompletions, helpful diagnostics and excellent developer experience.

Linting

While sublime has a dedicated linter plugin, you may not need it. Both eslint and stylelint have language server plugins. This way all your errors will be shown in the same place.

Prettier

Simply istall the JsPrettier plugin and you're all set.

Terminal

While sublime does not have a built-in terminal the Terminus package steps in to fill the gap.

Debugging

The Debugger plugin implements Debug Adapter Protocol or DAP, allowing you to debug your code without leaving sublime. While not as refined as VS Codes's debugger, it is functional and receives frequent updates.

Conclusion

Although this is a short guide, I hope it gave you some idea of Sublime Text's capabilities and how it can be set up to maximize your productivity and accommodate your daily workflows.

Parallelizing Tasks Using MongoDB

Lev Eidelman Nagar — Tue, 14 Dec 2021 06:50:58 +0000

Recently I published a post on our company's engineering blog.

Check it out if you work with MongoDB and want to find out how you can use it for parallel processing.

Creating Our First Controller

Lev Eidelman Nagar — Sat, 22 May 2021 16:45:53 +0000

In my last post we set up Inertia and Adonis. Now that we have a solid foundation to build upon, let us continue fleshing out our CRM app.

Our First Controller

In my previous post we used a closure route to test everything worked end-to-end. This is fine for simple one-off routes (things like the "about" page for instance), but for more demanding routes, we'll usually reach for a controller.
Let us therefore use ace to scaffold a resourceful controller:

node ace make:controller user -r

Take a moment to look at the new controller, Ace created for you. This is a basic template for our future CRUD operations:

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

export default class UsersController {
  public async index ({}: HttpContextContract) {
  }

  public async create ({}: HttpContextContract) {
  }

  public async store ({}: HttpContextContract) {
  }

  public async show ({}: HttpContextContract) {
  }

  public async edit ({}: HttpContextContract) {
  }

  public async update ({}: HttpContextContract) {
  }

  public async destroy ({}: HttpContextContract) {
  }
}

Now, let's connect some routes to the users controller.

Configuring Resource Routes

Open start/routes.ts and delete the route we previously created. Instead add this:

Route.resource('users', 'UsersController');

This doesn't look like much, but let's see what routes were automatically created for us:

node ace list:routes

Pretty neat! Adonis automatically created a route for each controller method.

Getting started with AdonisJS and Inertia.js

Lev Eidelman Nagar — Sun, 16 May 2021 20:24:44 +0000

In this tutorial we'll build a simple CRM app utilizing an awesome tech stack consisting of:

React - React really needs no introduction, since it's the most popular front-end framework around.
Inertia.js - Inertia allows you to create fully client-side rendered, single-page apps, without much of the complexity that comes with modern SPAs.
Typescript - A strongly typed superset of ECMAScript.
AdonisJS - A fully featured web framework focused on productivity and developer ergonomics.

If I were inclined to name things, I might call it the RITA stack.

Prerequisites

You should have the latest stable version of Node.js installed.
Some kind of code editor or IDE (if you're not sure, Visual Studio Code is a great option).

Now, let's build this thing...

Scaffolding a New App

Let's create a new Adonis project, by running the following from the terminal:

npm init adonis-ts-app@latest simple-crm

When prompted for the type of application you would like to scaffold select web:

We'll leave all options as their default values except Configure webpack encore for compiling frontend assets? which we'll set to true.

Let's cd into our project directory and continue.

Install Lucid ORM and Create Our User Model

We will use SQLite and LucidORM to store and retrieve our user data.

To install and set up LucidORM run the following in the terminal:

npm i @adonisjs/lucid

node ace configure @adonisjs/lucid

When prompted for the database driver you would like to use, choose SQLite.

Next, we will create our users schema.

Create the User Schema Migration

Run the following in your terminal to create the User schema migration:

node ace make:migration users

We will edit the migration script that was created for us and make a simple user schema consisting of a first name, last name and email:

import BaseSchema from '@ioc:Adonis/Lucid/Schema'

export default class Users extends BaseSchema {
  protected tableName = 'users'

  public async up() {
    this.schema.createTable(this.tableName, (table) => {
      table.increments('id').primary()
      table.string('first_name').notNullable()
      table.string('last_name').notNullable()
      table.string('email').unique().notNullable()

      table.timestamps(true, true)
    })
  }

  public async down() {
    this.schema.dropTable(this.tableName)
  }
}

Now, let's run our migration to create the user table:

node ace migration:run

With that out of the way, let's focus on our front end.

Configure Webpack-Encore for Typescript and React

By default Encore (the asset bundler provided to us by Adonis) is configured for Javascript, but since we want to use the same language throughout our app, let's modify it a bit.

First, let's install ts-loader and @babel/preset-react so encore knows how to handle Typescript files and JSX syntax:

npm install ts-loader@^8.0.1 @babel/preset-react --save-dev

Then, let's edit webpack.config.js by changing the following from:

Encore.addEntry('app', './resources/js/app.js')

To:

Encore.addEntry('app', './resources/js/app.tsx')
Encore.enableTypeScriptLoader()
Encore.enableReactPreset()

Also, let's rename /resources/js/app.js to /resources/js/app.tsx to match our previous changes.

Now, let's configure typescript for our client side code. Create a file called /resources/js/tsconfig.json and paste this minimal config in it:

{
  "include": ["**/*"],
  "compilerOptions": {
    "lib": ["DOM"],
    "jsx": "react",
    "esModuleInterop": true
  }
}

Lastly, let's install react:

npm i react react-dom @types/react @types/react-dom

Now we're ready to install and configure Inertia.js

Install and Configure Inertia Adapter

To install the Inertia adapter for Adonis, run the following command:

npm i @eidellev/inertia-adonisjs

Now let's configure the adapter by running:

node ace configure @eidellev/inertia-adonisjs

When prompted, please select to install the inertia adapter for react.

Setting Up the Client-Side Inertia Adapter

With everything installed, let's set up our root view. Open /resources/views/app.edge and add this script tag to the <head> section:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="icon" type="image/png" href="/favicon.ico">
  <!-- This -->
  <script src="{{ asset('assets/app.js') }}" defer></script>
  <!-- -->
  <title>simple-crm</title>
</head>
<body>
  @inertia()
</body>
</html>

Now, let's configure our app's entrypoint. Open resources/js/app.tsx and replace the code with:

import { InertiaApp } from '@inertiajs/inertia-react'
import React from 'react'
import { render } from 'react-dom'
import '../css/app.css'

const el = document.getElementById('app')

render(
  <InertiaApp
    // Pass props from the server down to the client app
    initialPage={JSON.parse(el.dataset.page)}
    // Dynamically load the required page component
    resolveComponent={(name) => import(`./Pages/${name}`).then((module) => module.default)}
  />,
  el
)

Next, let's add our first page component. Create a new react component in resources/js/Pages/Test.tsx:

import React from 'react'

const Test = () => <div>hello from inertia</div>

// All pages need to be exported as default
export default Test

Finally, let's configure a route for our new page. Open start/routes.ts and replace whatever is currently there with:

import Route from '@ioc:Adonis/Core/Route'

Route.get('/test', async ({ inertia }) => {
  return inertia.render('Test')
})

Now that we're all set, let's run our app and watch the magic happen:

node ace serve --watch # this will start both adonis and webpack dev server

When you visit http//localhost:3333/test you should see something like this:

Awesome!

To Be Continued

In the next posts in this series we will continue to flesh out our app and see some of the cool features of both Adonis and Inertia in action.

Open a Pull Request In Azure Devops From Powershell

Lev Eidelman Nagar — Sun, 23 Feb 2020 10:50:32 +0000

I'm naturally lazy and I like to be able to do things from the terminal as much as possible, so I came up with a small Powershell function to open a new pull requests in Azure Devops.
Feel free to adopt and adapt this to your own needs.

The code

Function Open-PullRequest([string]$targetRef="develop") {
  if (-not (Get-Command git)) {
    Write-Host 'Could not find git!' -ForegroundColor Red
    return;
  }

  $branch = git rev-parse --abbrev-ref HEAD --
  $remote = git remote get-url origin

  # This repo uses SSH
  if ($remote.startsWith('git@ssh.'))
  {
    $remote = $remote.replace('git@ssh.dev.azure.com:v3/', '')
    $remote = $remote.split('/')
    $remote = "$($remote[0])/$($remote[1])/_git/$($remote[2])"
    $url = "https://dev.azure.com/$remote/pullrequestcreate?sourceRef=$branch&targetRef=$targetRef"

    # Open default browser
    Start-Process $url
  }
  # This repo uses HTTPS
  else {
    $remote = $remote.split('@')
    $remote = $remote[1]
    $url = "https://$remote/pullrequestcreate?sourceRef=$branch&targetRef=$targetRef"

    # Open default browser
    Start-Process $url
  }
}

Installation

Copy this function into your Powershell profile.

Usage

Open-PullRequest # Will open a new pull request from your current branch to develop
Open-PullRequest -targetRef REMOTE_BRANCH # Will open a new pull request from your current branch to whatever branch you choose

Caveat

I've only tested this with Powershell Core 6.2.4 on windows 10

My git config

Lev Eidelman Nagar — Thu, 20 Feb 2020 08:09:56 +0000

This is my current git config. I'm mostly publishing this for the aliases, that I hope some will find useful.
I addition, I'm using the excellent git-interactive-rebase-tool and diff-so-fancy for easily squashing past commits and better looking diffs respectively.

  [user]
    name = USERNAME
    email = EMAIL

  [push]
    default = simple
    followTags = true

  [core]
    editor = nvim
    autocrlf = false
    safecrlf = false

  [alias]
    visual = !gitk
    # Get the current branch name (not so useful in itself, but used in other aliases)
    branch-name = !git rev-parse --abbrev-ref HEAD
    co = checkout
    # Create a new branch
    cob = "checkout -b"
    c = cherry-pick
    cl = clone
    st = status -sb
    br = branch
    # Delete local branch
    brd = "branch -D"
    # Pretty log
    h = log --pretty=format:\"%C(auto)%h %ad (%cr) %s%d [%Cgreen %an %Creset]\" --graph --date=short --all
    p = push
    # Push the current branch to the remote "origin", and set it to track the upstream branch
    pub="!git push -u origin $(git branch-name)"
    # Delete remote branch
    pd = "push --delete origin"
    cm = commit
    cmm = commit -m
    # Amend to last commit
    cma = commit --amend
    # Make a quick commit with WIP(work in progress) message
    wip = !git add --all && git commit -m "WIP"
    # Make a quick commit with WIP(work in progress) message and skip validations
    wipnv = !git add --all && git commit -m "WIP" --no-verify
    # Pull latest changes and sync current branch with remote
    sync = !git fetch --prune && git pull
    # Finds the commit where file was added. Usage: `git whatadded tsconfig.json`
    whatadded = log --diff-filter=A

  [pager]
    diff = diff-so-fancy.cmd | less --tabs=4 -RFX
    show = diff-so-fancy.cmd | less --tabs=4 -RFX

  [pack]
    windowMemory = 100m
    packSizeLimit = 100m


  [color]
    ui = true

  [color "diff-highlight"]
    oldNormal = red bold
    oldHighlight = red bold 52
    newNormal = green bold
    newHighlight = green bold 22

  [color "diff"]
    meta = yellow
    frag = magenta bold
    commit = yellow bold
    old = red bold
    new = green bold
    whitespace = red reverse

  [credential]
    helper = manager


  [sequence]
    editor = interactive-rebase-tool

Injecting Environment Variables into a React App

Lev Eidelman Nagar — Wed, 19 Feb 2020 07:53:21 +0000

When creating a react app using create-react-app, we may sometimes want to inject some environment variables at build time.
For instance, our team wanted to console.log the build time, app version and some git information when the app starts.

This is the solution we came up with.

The Build script

We added a node script to scripts/build.js. The script uses shelljs to append information to the environment and run react-scripts and simple-git to execute git commands.

const path = require('path');
const shell = require('shelljs');
const simpleGit = require('simple-git');
const { version } = require('../package.json');

const args = process.argv.slice(2);
const isDev = args.includes('--dev');

if (!shell.which('git')) {
  shell.echo('Cannot build without git');
  shell.exit(1);
}

if (!shell.which('yarn')) {
  shell.echo('Cannot build without yarn');
  shell.exit(1);
}

const workingDir = path.resolve(__dirname, '../');
const git = simpleGit(workingDir);

function getCurrentBranch() {
  return new Promise((fulfill, reject) => {
    git.status((err, status) => {
      if (err) {
        reject(err);
        return;
      }

      fulfill(status.current);
    });
  });
}

function getCurrentCommit() {
  return new Promise((fulfill, reject) => {
    git.revparse(['HEAD'], (err, hash = '') => {
      if (err) {
        reject(err);
        return;
      }
      fulfill(hash.slice(0, 7));
    });
  });
}

(async () => {
  try {
    const branch = await getCurrentBranch();
    const commit = await getCurrentCommit();
    const buildTime = new Date().toUTCString();

    shell.env.REACT_APP_VERSION = version;
    shell.env.REACT_APP_GIT_BRANCH = branch;
    shell.env.REACT_APP_GIT_COMMIT = commit;
    shell.env.REACT_APP_BUILD_TIME = buildTime;

    if (isDev) {
      shell.exec('yarn react-scripts start');
      return;
    }

    shell.exec('yarn react-scripts build');
  } catch (err) {
    shell.echo('Failed to gather build info', err);
    shell.exit(1);
  }
})();

We substitute react-script in package.json for our build script:

...
  "scripts": {
    "start": "node ./scripts/build --dev",
    "build": "node ./scripts/build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
...

In the app

We added src/utils/printBuilInfo.js. It prints out our environment variables in a style inspired by Vue devtools.

function print(title, info) {
  // eslint-disable-next-line
  console.log(
    `%c ${title} %c ${info} %c`,
    'background: #f26d21; padding: 1px; border-radius: 3px 0 0 3px;  color: #fff',
    'background: #009eed; padding: 1px; border-radius: 0 3px 3px 0;  color: #fff',
    'background:transparent',
  );
}

export default function printBuildInfo() {
  print('Version', process.env.REACT_APP_VERSION);
  print('Branch', process.env.REACT_APP_GIT_BRANCH);
  print('Commit', process.env.REACT_APP_GIT_COMMIT);
  print('Build Time', process.env.REACT_APP_BUILD_TIME);
}

We use it in src/index.js:

import React from 'react';
import ReactDOM from 'react-dom';
import * as serviceWorker from './serviceWorker';
import App from './App';
import printBuildInfo from './utils/printBuildInfo';
import './styles/index.scss';

printBuildInfo();

ReactDOM.render(<App />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();