DEV Community: Michał Gacka

How to load environment variables in Svelte

Michał Gacka — Mon, 28 Feb 2022 09:52:07 +0000

Svelte is a new, up-and-coming framework for building fast web applications. In contrast to React, it does a lot of the heavy lifting in a compile step instead of in the browser. It's very clever and comes with enormous advantages but can also have its pitfalls for developers used to the more popular frameworks. In case of the environment variables, one can't just import dotenv wherever and assume it will work - a replace plugin of rollup (the bundler) has to be used instead. This tutorial uses yarn for a package manager and would work the same with npm.

Using dotenv and rollup's replace plugin to load environment variables

In order to be able to load environment variables like we're used to: process.env.<variable-name>, we will use @rollup/plugin-replace together with dotenv.

The magic will happen in the rollup.config.js file which tells rollup how to build our project. First, go ahead and install the required dependencies using yarn or npm. I'll assume yarn. Run yarn add --dev @rollup/plugin-replace dotenv and create a .env file (remember to git ignore it) in the main folder of your repo.

Now, in your rollup config, tell rollup to use the replace plugin, define which files it should include in the replacement procedure and which strings you want to replace:

  .
  .
  .
  plugins: [
    replace({
      include: ["src/**/*.ts", "src/**/*.svelte"],
      preventAssignment: true,
      values: {
        "process.env.TESTVAR": "'replacedtestvar'"
      }
    }),
  .
  .
  .

Note that the replacement happens at compile time which means that if you don't wrap the values of the provided dictionary in an additional quotation, javascript will be looking for a variable of that name instead of understanding that it was supposed to be a string. Thus, in order to use the familiar process.env.<variable-name> we will make a simple transformation of our config loaded using dotenv.

First import dotenv at the top of your rollup.config.js:

import { config } from 'dotenv';

Then proceed to transform the env. variables to suit the replace plugin:

const configToReplace = {};
for (const [key, v] of Object.entries(config().parsed)) {
  configToReplace[`process.env.${key}`] = `'${v}'`;
}

And finally adjust the plugins option of the exported rollup config:

  .
  .
  .
  plugins: [
    replace({
      include: ["src/**/*.ts", "src/**/*.svelte"],
      preventAssignment: true,
      values: configToReplace,
    }),
  .
  .
  .

Make sure to adjust the include option of the plugin and then you can joyfully write process.env... to access the properties you loaded from your .env file.

You need a manager, not a boss 🤝

Michał Gacka — Sat, 29 Jan 2022 20:27:30 +0000

In a conversation about how a lot of part-time workers vs a few full-time workers can affect a team, my tech friend recently asked me: “Are managers a relic of the past or are they absolutely essential?” Both, I answered.

A manager as we know them is usually our boss. Someone that holds the superior power and the superior responsibility and organizes, controls, administers an organization or a group. That, I argued, is indeed unnecessary and will become less and less practiced.

In that model, a manager is not telling people what to do anymore but merely facilitates the work and is an equal unit of them.

But it doesn’t mean that we don’t need managers at all. On the contrary! As the structures flatten, and responsibility spreads to more nodes, more meta work (organizing, communication, planning, synchronizing, etc. – as opposed to development work) will emerge and we need people who specialize in those areas to keep our collaboration smooth and goals on target.

A great example of that is the transition from traditional project management to self-organization. Scrum moves away from someone telling the team what to do and towards a doocratic model of the responsibility in an area belonging with those who actually perform the tasks in that area. In that model, a manager is not telling people what to do anymore but merely facilitates the work and is an equal unit of them.

Seems obvious? It should be. But still, often I see hierarchical legacies of the structures built up within an organization – or even psychological legacies of operating within hierarchical structures – interfering with the very foundation of scrum processes limiting the flexibility of the participants and having a plethora of negative consequences for the individuals, the team, and the products.

I strongly believe in driving the change even if it doesn’t seem to be your direct responsibility.

So what can you do as a member of a confused team? I strongly believe in driving the change even if it doesn’t seem to be your direct responsibility (the more it doesn’t, the more you should!). Don’t just focus on writing the code. Go learn a little about project management, product management, and different ways of organizing teams. Start having those conversations with your colleagues and your managers. Maybe they too can become more of facilitators than bosses. You have the power to shape your environment, use it.

Impactful Coding Communities?

Michał Gacka — Tue, 16 Mar 2021 12:29:39 +0000

I've been toying with the idea of creating some kind of a dev community that only wants to apply their skills to socially impactful, "good" or hippie projects. A place where programmers with shared values of improving the world around them could meet, join together into workgroups, explore ideas, etc.

I personally find it difficult to know where to direct my energy whenever I decide to leave my previous job/project and would benefit a lot from having a network that I know focuses on things that I care about. I could then reach out and easily find opportunities based on the trust developed in that community.

Do you know of any initiatives like that? Would you want to be a part of it?

// forgive the creepy cover image -> that's what google thinks a hippie techie looks like

Always write at least 1 end-to-end test. You'll love it, I promise.

Michał Gacka — Mon, 01 Mar 2021 14:56:20 +0000

The cover image shows you how I felt the first time I ran an end-to-end test of a web service I was developing. You can feel like that too. If you always write at least one end-to-end test as soon as you start developing a new project or a module in your project. Why?

Why?

Because even in the early stages of development it will save you a lot of headaches and time: you won't have to check manually if things work every time you make changes to the code.

I shed a tear every time I think about how much time I've spent in my early dev years having to run the code and check that things work every time I changed an env variable name or fixed a bunch of linting errors.

Bonuses

by being lazy like that, you'll join the high echelons of programmers who have the test framework always set up and ready to accommodate more tests when you feel fancy enough to add some
if you're anything like me and you tend to postpone writing tests on hobby projects, following this principle will help you conceptualize the problem as not-a-big-deal-at-all since you only promised to add 1 test (the rest will eventually follow)

What kind of test to write?

For a front-end, it's nice usually nice to have some kind of simple click-through with a login step (if your application consists of such) and making sure that all the views/pages are accessible and rendered. For a micro-service or an API, it's great to have it accept some data and check the response or that it saved things in the database correctly.

Remember git hooks

You got this far in automating something that takes your time unnecessarily. Then why run the npm test command manually? Husky makes git hooks simple and fun. You just write a simple script, call it pre-push and your tests will run automatically before the code gets pushed to the remote.

Remember Docker

Synchronizing applications and services for testing can be a headache so make sure to have a nice and clean docker setup so you can easily spin up containers that depend on each other for testing purposes.

And if you're not on the Docker train yet, you should definitely incorporate DevOps skills into your practice. It's a must.

How to get an accurate position estimate from the Geolocation API in JavaScript

Michał Gacka — Mon, 08 Feb 2021 15:15:32 +0000

The Geolocation API has been introduced into modern browsers many years ago and hasn't changed much since yet it still can waste many hours of your time if you don't know how to work with it. There's a lot of magic happening behind the scenes that isn't properly explained in the documentation. Here's a straightforward way to get an accurate estimate without you having to spend the 2 days I've spent figuring out why my location estimates look like out of a random number generator.

There are 2 functions you can use to ask the browser for location estimates: getCurrentPosition() and watchPosition(). So far so good: the first will spit out 1 position on success, while the second will keep throwing new positions at you as they are updated. It's important to note that the GeolocationCoordinates object that we get as a result of either of these 2 functions contains the estimated position and accuracy of the measurement in meters.

For my application, where the user was supposed to trigger a location measurement it seemed obvious to use the getCurrentPosition() since in that case, I wouldn't have to take care of storing the state of change coming from watchPosition() and having to use clearWatch() to stop listening at an appropriate time. It seemed perfect. And turned out to be completely useless.

The getCurrentPosition() accepts an options object where you can turn enableHighAccuracy boolean to true. It comes with high hopes and an even larger disappointment. Even with the boolean, the measurements I'd get from my phone would have an accuracy of thousands of meters which rendered them virtually useless for what I needed.

Enter watchPosition(). After reading some obscure blog I don't remember the name of that went into details of how the GPS module might work in the phone, I learned that it might take a few seconds to warm up and spit out a correct position. And that is the crucial piece of knowledge you need to solve this problem. One that should definitely be explained in more depth in some of the official sources that explain how to use this API.

Knowing that I implemented my logic using watchPosition() instead and it turned out that indeed, magically the accuracy again starts at thousands of meters but, after a few seconds of these bad measurements, the GPS kicks in and provides estimates with a few meters of accuracy. These, finally, make sense for my application.

Here's an example of a function I use within the React's useEffect() hook. Note the returned function that allows me to clear the watch by returning it from the hook.

const readLocation = (
  setLocation: (location: ILocation) => void,
  setError: (errorMessage: string) => void,
  setAccuracy: (acc: number) => void
) => {
  if (navigator.geolocation) {
    const geoId = navigator.geolocation.watchPosition(
      (position) => {
        const lat = position.coords.latitude;
        const lng = position.coords.longitude;
        setLocation({ lat, lng });
        setAccuracy(position.coords.accuracy);
        console.log({ lat, lng }, position.coords.accuracy);
        if (position.coords.accuracy > 10) {
          showErrorSnackBar("The GPS accuracy isn't good enough");
        }
      },
      (e) => {
        showErrorSnackBar(e.message);
        setError(e.message);
      },
      { enableHighAccuracy: true, maximumAge: 2000, timeout: 5000 }
    );
    return () => {
      console.log('Clear watch called');
      window.navigator.geolocation.clearWatch(geoId);
    };
  }

  return;
};

That's all you need to get accurate estimates from the Geolocation API. Let me know in the comments if this worked for you ☀️

EDIT:
Here's also a React hook version of a similar functionality (still imperfect but a good starting point for your own Geolocation hook):

const useLocation = (
  enabled: boolean,
  accuracyThreshold?: number,
  accuracyThresholdWaitTime?: number,
  options?: PositionOptions
): [ILocation | undefined, number | undefined, string | undefined] => {
  const [accuracy, setAccuracy] = React.useState<number>();
  const [location, setLocation] = React.useState<ILocation>();
  const [error, setError] = React.useState<string>();

  React.useEffect(() => {
    if (!enabled) {
      setAccuracy(undefined);
      setError(undefined);
      setLocation(undefined);
      return;
    }
    if (navigator.geolocation) {
      let timeout: NodeJS.Timeout | undefined;
      const geoId = navigator.geolocation.watchPosition(
        (position) => {
          const lat = position.coords.latitude;
          const lng = position.coords.longitude;
          setAccuracy(position.coords.accuracy);

          if (accuracyThreshold == null || position.coords.accuracy < accuracyThreshold) {
            setLocation({ lat, lng });
          }
        },
        (e) => {
          setError(e.message);
        },
        options ?? { enableHighAccuracy: true, maximumAge: 2000, timeout: 5000 }
      );
      if (accuracyThreshold && accuracyThresholdWaitTime) {
        timeout = setTimeout(() => {
          if (!accuracy || accuracy < accuracyThreshold) {
            setError('Failed to reach desired accuracy');
          }
        }, accuracyThresholdWaitTime * 1000);
      }
      return () => {
        window.navigator.geolocation.clearWatch(geoId);
        if (timeout) {
          clearTimeout(timeout);
        }
      };
    }

    setError('Geolocation API not available');
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [enabled, accuracyThresholdWaitTime, accuracyThreshold, options]);

  if (!enabled) {
    return [undefined, undefined, undefined];
  }

  return [location, accuracy, error];
};

It lets you specify an accuracyThresholdWaitTime which decides how long the watchLocation will listen for before deciding that the accuracy is not good enough (for example when someone is indoors the accuracy will never get better than ~10m and you might need it to reach ~3m to serve your purpose).

5 unexpected advantages of working with more experienced developers

Michał Gacka — Thu, 17 Dec 2020 21:57:35 +0000

I've spent the last year and a half developing the software part of a bigger product as the only software engineer in a startup that I cofounded. It had many benefits but also made me realize these surprising benefits of having more experienced colleagues around.

1. They will tell you that your linter is taking too long to recompute

Way too often, as an inexperienced developer, I just wasn't sure what my experience in working with technology should be like. I'd choose libraries that were difficult to use and spend time with programming languages I didn't enjoy working with.

Some time ago, I had the experience of using TSLint with up to a 2-second delay on changes without knowing that it shouldn't be like that and how important consequences it will have for my productivity and code quality (as I'm writing this, it sounds quite obvious but I'm sure you can think of times when obvious problems or solutions hid from you in plain sight).

If there was a colleague next to me with more experience using TypeScript they would immediately point out to me, how crucial it is to fix this issue.

2. You'll be reminded about taking breaks and inspired to take on different work organization methods

It's way too often overlooked how important it is to have patterns of organizing your work as a developer. And there is no better way of realizing that you're bad at it than by observing your more senior co-workers. Even if you don't realize it yet, you'll at least be reminded to take a break when they do it instead of falling into a 5h coding frenzy and waking up unproductive and hungry on the other side (still happens to me occasionally 🙃).

If you're not doing it already, experiment with the Pomodoro technique to figure out what kind of rhythm of work and breaks makes sense for your body and your mind. For Windows, I recommend this super simple app called Focus 10.

3. They will (hopefully) teach you how to respectfully disagree

One of the most important policies in life I have is direct and honest communication. And there's almost nothing else that puts it at a test as much as discussions and conflicts with more senior team members. If you don't get to practice communicating your point of view without causing too many negative emotions to your team members, you'll lack one of the most crucial skills to maintaining healthy dev-dev relationships.

A quick tip that used to help a lot in a small team I was a part of: whenever you seem to be heading towards a disagreement, ask each other "how strongly do you feel about this from 1-10?". We'd often find that even though a person gets heated up in the discussion they actually don't mind letting the other one take the lead on the decision - they would answer e.g. 2 while the other person said 9.

4. They will make you feel smart

Coding can be a very solitary practice. Working alone you might spend weeks or months without much appreciation coming in from the outside world (heck, when you're learning to code it might feel like you've spent years just making mistakes and writing useless code - if you feel like that: hit me up, I'll have some advice of how to structure your learning process better).

But there aren't many moments more rewarding in a programmer's career than the times when someone you look up to reaffirms you with a well-deserved compliment. Coders are often a tough bunch, so if you find a colleague that is a solid programmer, knows how to communicate, and is willing to guide you, sit close-by and learn to listen.

5. You'll notice they changed their font in vscode and start using ligatures

I'm almost joking. But not really. A few weeks ago in the darkness of the pandemic and the Danish winter combined my motivation to program was revived but something as silly as customizing my vscode experience. I changed my vscode font to Fira Code, started using these cool coding ligatures (special characters that combine multiple other characters, e.g. => will become an arrow that looks like 1 character) I saw at my colleagues' screens years ago but somehow never tried myself, and I installed the Bracket Pair Colorizer extension. Together it made my IDE shine and my brain feel like it's my first day of programming.

Of course, I'm exaggerating a little and the excitement didn't last very long but what did stay with me is the feeling that I am in charge of my own experience. Every time I notice the colorful brackets or the ligatures it reinforces that feeling (I argue in another article for why I think it's so important to take an active part in shaping your coding environment).

Ok, but what if someone just started to learn to code or for other reasons doesn't have access to more experienced colleagues? Well, there are some alternatives: read blogs, attend conferences (when there happen to be no raging pandemics at that moment), watch vlogs to understand better how people with more experience structure their work and coding approach. Here's a cool example of a blogger who put a lot of effort into creating a customized environment that suits his needs perfectly and who inspired me to customize my vscode.

But in the end, I'd say programming is a little bit like music. You can do it alone but in the end, as a social creature that we happen to be, you'll regret not having people around you while on your path to becoming a great coder.

Would you use a chrome extension that makes you google SO answers faster? 🚀

Michał Gacka — Wed, 16 Dec 2020 15:14:23 +0000

I found lately that whenever I'm learning a new language or library or I focus on something very specific (like fixing typing errors in TypeScript) I'd lose a lot of time refocusing from vscode to Chrome, retyping a similar query, and having to select the first search result. So I made a chrome extension that does that and I wonder if you'd like to beta test it.

![Brisk Logo](https://dev-to-uploads.s3.amazonaws.com/i/554brdd6eiiyhp2443lw.png) ^{*A great excuse to draw a happy squirrel. Brisk's logo.*}

It's all based on the assumption that Google is much better at searching SO than SO's built-in search function. The chrome extension is called Brisk and it lets you define a global shortcut (you can trigger it directly from your ide) that will:

focus chrome,
open up a window automatically into which you can type in your query
it will then run that (optionally with a prefix defined by you - e.g. 'python' so that you don't have to retype the beginning all the time) query into google
and select the first StackOverflow answer

It's still a bit experimental and even though it works for me I wonder if you'd be up for trying it out (in dev mode before I release it) so that I can adjust it to your needs ☀️

Coder's biggest and most hidden enemy. Creeping up on you right now

Michał Gacka — Fri, 11 Dec 2020 13:54:55 +0000

It's to a programmer like a pandemic to a society. It creeps up on you. Slowly. There are some tiny signs of it at first but... who would bother? Then it becomes more and more obvious but to an untrained eye, it still seems ignorable. I mean, it's not like it's that bad, right? Life's a bit harder: it gets harder to focus, things are getting a little bit out of control, few bugs here and there creep into the application. But for sure, that can't yet justify the effort that would have to be applied to resolving it, can it?

Until - in case of a pandemic - we wake up as a society with overloaded hospitals, a badly-hit economy, and a lack of organizational structure to deal with the exponentially arising problems.

"It creeps up on you. Slowly. There are some tiny signs of it at first but... who would bother?"

In case of clutter and disorder, a programmer wakes up with a couple of glasses, dirty plates, a few used face masks, unnecessary gadgets, a few useless cables, and an endless list of how-did-this-even-get-here items on their desk, laptop's desktop overflown with icons and files that should have never made it to the front of his workspace, code-base with hundreds of ignored linting errors, and a general feeling that it would take more energy to sit down and put a few hours into the project than to pick up a new career.

If there's one thing you should do today, let it be this: unclutter. Your desk, your computer, your project. And yourself. If you can, just pause anything else you're doing right now, set a timer for 1 hour, and try to clean as much of the unnecessary mental barriers that exist between you and the joyous motivation to write code that you hopefully still can remember is possible. Your future self will thank your now-you. Trust me.

"...a general feeling that it would take more energy to sit down and put a few hours into the project than to pick up a new career"

Not enough time? Do the same thing tomorrow. First thing in the morning. Start your day by offering yourself the gift of a clear, uncluttered work environment that will surely translate into higher efficiency, less stress, and ultimately a happier life.

If you have previous practice meditating or practicing mindfulness, I believe it is helpful to try to apply the same kind of techniques to observing when we decide to cut corners and start piling up the clutter that ultimately creates new corners - unnecessary obstacles to overcome. Try really paying attention to that feeling when you type ": any" to avoid having to come up with a type for that variable or when you sit down to work in a dirty workspace instead of decluttering and cleaning it first.

"Start your day by offering yourself the gift of a clear, uncluttered work environment that will surely translate into higher efficiency, less stress, and ultimately a happier life"

And then try to observe how pleasurable it is and how positively it affects your motivation when you feel that your workspace and your code are clean. How good it feels when all your TypeScript variables explain their structure upon hovering. How calm your mind is when you sit down at a clean, spacious desk with that beloved cup of warm coffee. How good life feels when you are the one in control.

Here's a quick challenge for you: post in the comments a picture of your desk or your laptop's desktop (or both) right here right now. Without cleaning or changing anything 🤨🧐😀

Anyone else worked on a covid19-related project? 🤓

Michał Gacka — Fri, 11 Dec 2020 13:49:55 +0000

The moment the pandemic started I got so overwhelmed by having to compute the consequences of such an unprecedented situation that I couldn't focus on my day job and felt like I had to focus on doing something related to covid19. It helped and I learned a lot in the process.

I ended up making a data visualization page in TypeScript and React that allows for comparing countries' infection trajectories and visualizes the cases and deaths on a simple map. I called it COVID19.PINK because the color domains were almost the only ones available for covid19 🙃

It's open-source if you want to check out the details.

Did you build anything related to the coronavirus? 🤓 What was your motivation? I'd love to see your projects.

Don't struggle with extending the service worker in Create React App anymore. Upgrade to version 4!

Michał Gacka — Mon, 07 Dec 2020 14:50:28 +0000

No need to struggle with how to customize and extend the service worker without ejecting Create React App anymore. Version 4, released in October 2020, comes with a service worker file available for extension in the src folder.

I wrote a post about the simplest way to extend the default service worker in CRA to help others who were dealing with this task. A strangely easy task requiring a dreadful amount of research and trial and error. But that was before I found out that there is an even simpler way: upgrading to the new CRA version.

The previous post generated some attention so I figured that I'm not the only one, who doesn't realize that one can now access the Service Worker file and edit it directly in the new CRA version.

Simply initialize the project with:
npx create-react-app my-app --template cra-template-pwa

or:
npx create-react-app my-app --template cra-template-pwa-typescript

And the service worker will be available for extension the src folder. Check out the official guide for more information and instructions.

Upgrading is quite straightforward too. I recommend creating the new project on the side, comparing the package.json files to update the old one, copying and merging the files generated in the src folder to the old project, and then fixing compile errors if any occur. It didn't take more than 20 minutes for my relatively large project.

Supporting choiceful (object and array) destructuring in JavaScript and TypeScript

Michał Gacka — Tue, 01 Dec 2020 12:27:13 +0000

The joy of object and array destructuring is most likely known to you (check out an example below if it's not 🙂). But what about the joy of being able to choose between them while using the same function? How exciting would that be!?

Wait, but why? Well, because each has its upsides and there is usually no good enough reason to force the developer to use one of them by design. Array destructuring allows you to more succinctly rename the variables but requires remembering the order, while object destructuring forces you to remember the name but doesn't mind the order.

What are object and array destructuring?

// object destructuring
const o = {
  firstN: 'Plants',
  v: 'need',
  secondN: 'water'
}
const {firstN, secondN} = o;
console.log(secondN); // water

// array destructuring
const a = ['Plants', 'need', 'water'];
const [firstNoun, verb] = a;
console.log(firstNoun); // Plants

They are a succinct way to retrieve variables from a more complex type. Easy to use and easy to read. If used adequately. And in order to maximize the chance that they are indeed used correctly, you might want to defer the choice for which one to use by allowing both when returning from your functions. Just like the useInView() React Hook did which inspired me to write this.

First in pure JavaScript:

const veryImportantSelfContainedLogic = (n) => {
  const result = ['Plants', 'need', n, 'waters'];

  result.firstWord = result[0];
  result.anotherWord = result[1];
  result.notAWord = result[2];
  result.lastWord = result[3];

  return result;
};

And then in TypeScript (highly recommended if you haven't made the transition yet):

type VeryImportantSelfContainedLogicResponse = [string, string, number, string] & {
  firstWord: string;
  anotherWord: string;
  notAWord: number;
  lastWord: string;
};

const veryImportantSelfContainedLogic = (
  n: number = 5
): VeryImportantSelfContainedLogicResponse => {
  const result = ['Plants', 'need', n, 'waters'] as VeryImportantSelfContainedLogicResponse;

  result.firstWord = result[0];
  result.anotherWord = result[1];
  result.notAWord = result[2];
  result.lastWord = result[3];

  return result;
};

The developer using your function can then choose which type of restructuring to use depending on their mood (or some other considerations if one finds them more important):

// decided to rename the second variable in comparison to the function author's intention
const [firstWord, secondWord] = veryImportantSelfContainedLogic(3); 

// has to follow the naming
const {firstWord, anotherWord} = veryImportantSelfContainedLogic(5);

// or redefine it like so
const {firstWord, anotherWord: secondWord} = veryImportantSelfContainedLogic(5);

Neat, isn't it? ☀️

Let me know in the comments if you see any downsides in supporting choiceful destructuring by default or if you're all in on the idea 🤓

The easiest way to extend or customize Create React App service worker without ejecting

Michał Gacka — Sun, 06 Sep 2020 12:50:29 +0000

Create React App (version before 4.0.0) by default includes a hidden Service Worker that will do some background magic for you in order for your app to be recognized as a Progressive Web Application. But if there's one pitfall of CRA, it's definitely how closed the configuration is and how difficult it is to modify / extend / customize it without ejecting (taking full control of the configuration) the application. Here, I discuss and present what I found to be the simplest way to extend the out-of-the-box service worker functionality.

EDIT: On the 23rd of October 2020 Create React App 4.0.0 has been released which simplifies the process of extending the default service worker immensely, so it might be a good idea to consider upgrading your project instead of using the workarounds I describe below. You can now just initialize the project by using the PWA template and it will generate the service worker file for you in the src folder which you can just add your custom code to. Check out the official instructions.

In my case, for the purpose of adding a background process to take care of firebase messaging for push notifications but this trick should work in any other case as well.

There's a multitude of articles trying to solve the problem but for some reason, most of them are overly complicated and are a pain to make them work in practice. That's because most of them overlook this wonderful utility: cra-append-sw. It lets you easily append the code you need to the existing service worker when building a production-ready app and also place a separate worker file in the public folder so you can register it yourself when running the development server.

It's as simple as installing the package, creating the service worker file in your main folder ('firebase-messaging-sw.js' in my case), and modifying your package.json file like this:

...
"start": "cra-append-sw --mode dev --env ./.env ./firebase-messaging-sw.js && react-scripts start",
"build": "cra-append-sw --env ./.env ./firebase-messaging-sw.js && react-scripts build",
...

Also you need to remember to take care of registering the service worker when your application runs via a development server (CRA will only register its own service worker so in development, the separate file created in the public directory has to be registered separately). Here's a snippet out of my index.tsx file which is the entry point for my react application:

This is to make sure that when cra-append-sw runs in dev mode (and thus generate the worker in the public folder instead of appending it to the react service worker) you register it manually.

That should be all you need. Neat and simple in contrast to other hacky tools trying to accomplish the same.

One of the hardest issues to solve with these pipelines I've found was how to use environment variables within the service worker in order to configure the firebase access key and other secret variables I had in my .env file. This solution solves it because the code is ran through the webpack pipeline before it's outputted both in the normal mode and the dev mode. Meaning you can access the process.env object in your custom service worker code.

I hope this saves you some pain and you live happily ever after with your new service worker functionality included in your Create React App.

Additional notes & edits:

As pointed out by @sjbuysse in the comments when cra-append-sw runs in the production mode there is no reason to register the service worker manually. It is necessary though in the dev mode, thus the gist I appended from my index.tsx file. I updated it now with a check for the environment to only run it in dev. Here's the relevant part from cra-append-sw documentation:

dev creates public/<file> instead of appending the code to build/service-worker.js
build creates build/<file> instead of appending the code to build/service-worker.js

A little bit beyond the scope of the post but requested in the comments: the firebase-messaging-sw.js that I ended up using. It's a Frankenstein of some solutions I found online if I remember correctly but I can't find the sources now to credit them. Let me know in the comments if you recognize the gist ☀️
As pointed out by @sjbuysse it might be necessary to pass your service worker registration object to the firebase messaging getToken() options in production (when you append the firebase service worker to your CRA service worker) but for some reason it worked for me without it.