How to fix "Uncaught ReferenceError: process is not defined" error

Ever run into this dreaded issue when working with Javascript or – preferably – Typescript?
Nothing is more frustrating than happily coding away, deciding you want to increase the security abstraction layer a bit – or perhaps you subscribe to the 12 Factor App – only to get met with this error.

Thankfully, you’ve come to the right place, as I will tell you exactly how to fix this issue!

Let’s dig in, shall we?

The root of the issue

Javascript is actually telling you everything you need to know in order to solve this issue, right in the error message, but it may not be immediately clear what is going on. Hopefully I can clear that up!

The reason this is happening, is because for some reason you are not allowed to access process – exactly as the error describes – which could happen for a variety of reasons.

I will go over each of them in-depth, but they are:

Not properly picking up a new package
Server having a bad day / TS compilation issue(s)
Missing node types
Improper library versions
Not having a backend

Now, just for the sake of adding some context to make sure you and I are on the same page, for the rest of the article I will assume you are doing work on your localhost, on an unspecied (and unimportant to the point of this article) port.
Additionally, as you may have guessed, I am going to assume you are using Typescript, although these fixes should work in plain Javascript too.

Lastly, these issues are listed in order of occurrence for your convenience, as I’ve seen this error times enough to have found a good process for debugging it, so start from the top as that is the most common reason 🙂

The reasons this error shows up, and possible fixes

Not properly picking up a new package

Perhaps you’ve recently installed the library that was supposed to give you the freedom to start setting environment variables on process.env such as the popular dotenv library.

If you have just installed this package, I’ve learned there’s always two things you should do to ensure things keep rolling smoothly:

Properly import the package
Restart your development server

To properly import the package, specify it as such:

import dotenv from 'dotenv';

I’ve seen plenty of projects write their import as:

import * as dotenv from 'dotenv'

While this should work, I had many issues with it in the past, until I decided to go with the ´cleaner´ option.

Secondly, it’s important that you fully stop and then restart your development server.
Because environment variables are injected when starting the server, they won’t automagically work with a restart as all your other code changes will.

If you’re using something like nodemon , tsc --watch , ts-node or even ts-node-dev (which I’m a big advocate for), that means killing the process (typically with a CTRL-C) and starting it again.

The command line way to kill the process

As most of these tools require a bit of command line knowledge to properly kill, it may be worth having as a handy tool in your back pocket, should you need to force a restart.

These two will work on MacOS and Linux, and should work on WSL but it’s been a while since I’ve worked on windows so I don’t know for sure.

Find the process number

First run the following command, with your project folder name. In my examples I use backend:

ps aux | grep 'backend'

On this list you should identify the path in which your project folder is included, plus a node command running your npm start (or alternative) command.

This should give an output akin to this:

<username>           18155   0,0  0,2 420280240  31600 s003  S+   Fre02pm   0:07.76 /Users/<username>/.nvm/versions/node/v18.17.1/bin/node -r /var/folders/6l/qpslfpxx2pbchkmd8mjxdsww0000gn/T/ts-node-dev-hook-0354302670886284.js /Users/<username>/code/backend/node_modules/ts-node-dev/lib/wrap.js app.ts --watch

From here we need to make a node of the Process ID (PID), in this case it is 18155.

Please note this changes every time you launch your development server, so you will need to do this every time you need to force shut down the server.

Kill the process

Once you have the process number, you simply need to kill it. Replace the PID in the following command with your PID:

kill -9 18155

That’s it! You have successfully force closed your development server.

Did it work? Great!

No? Well let’s try the next thing then..

Server having a bad day / TS compilation issue(s)

This one is short and sweet. Bit of a weird issue.

This happens frequently to me, on a weekly – if not occasionally daily – basis, for unknown reasons.

I’ll be happily coding away, on something completely unrelated to process.env by the way, and for whatever reason the compiler or development server is having a bad day and decides to throw a hizzy fit.

If you for some inexplicable reason all of a sudden just get the error in question, and you have not touched any process related code or replaced dotenv or something of that nature, simply try restarting your development server or run the tsc compilation again.

Mostly, this fixes the issue for me!

Missing node types

Another reason however, could also be that you haven’t installed the necessary types for your node version, which will confuse your editor and can give you this error in-editor, even if TS will compile just fine.

The simple fix here is to install the appropriate version of types/node .

What I mean with appropriate, is you should be installing the version of the types that matches the node version you are running. So if you are on node version 14, you should be installing types for node 14 as so:

npm install --save-dev @types/node@14.14.28

That should quelch the nasty error for you! But if it didn’t, read on..

Improper library versions

A worse situation to be in, is if you find yourself with an improper node version.
There could be a couple of situations in which we consider a version improper, but at its core it happens because there is a mismatch between a library and the node version.

This could happen because the library is just fetching the newest version, and it doesn’t play well with your version of node . This is true particularly if you are adding dotenv to an older codebase.

It could also be that you have an old version of a given library – such as dotenv – and have recently updated your node to a newer version, making the two incompatible.

This case is much less common and will require some debugging on your own, but a good starting point is getting friendly with the command npm outdated which can give you an indication of what might be going on.

Not having a “backend”

Last on the list, we have a unique case I am seeing more and more often.

As the wonderful world of frontend development keeps developing amazing tools and framework at break-neck speed, the documentation for errors arising on their behalf, struggle to keep up.

This is one such case.

A simple oversight, but if you’re developing on a newer frontend framework it may simply be that process actually does not exist.
This is because process is a feature of node, or more specifically, running your code in a server environment and not something that is a feature of javascript itself.

In other words, if you are building code that builds from something like vite it may very well be that process does not exist.

However, the Vite developers are smart and obviously aware of this, and have wisely chosen to give you the same experience with the similar property import.meta.

So instead of

process.env.variable

your code becomes:

import.meta.env.variable

import.meta is a part of the javascript definition, and is an opt-in, when using a modules-based (ESM) approach to JS. This is the standard in browsers, and many modern frameworks, as we are increasingly migrating away from the old way of doing things, CommonJS (CJS).

That also means that import.meta is only available within modules, so that means if you’re on a newer NodeJS (yes, backend!) project, you may even need to do import.meta there too, although process.env should also be available.

Conclusion

If these steps didn’t help you resolve the issue, please don’t hesitate to reach out to me so I can add your solution to the list!

If it did, and you are looking to level up your Typescript game, I would be honored to send you an email every week or two with Typescript tips and tricks, mostly focusing on NodeJS and a backend environment 👇

Thanks for reading!