Launching react app locally using netlify-cli crashes cli


I’ve been building React apps without any issues for a long time. Suddenly, the netlify-cli crashed just after unzipping a function.

I started getting this weird error:

Warning: TypeError: Cannot read properties of undefined (reading 'routes')

At first, I thought it was related to an update I did in the UI part and that, for some reason, the BrowserRouter was broken.

Removing it completely from the project didn’t help, though.

So, I enabled debug logging by passing the --debug argument like so:

netlify dev --debug

This gave me the place where it all crashed:

 ›   Warning: TypeError: Cannot read properties of undefined (reading 'routes')
 ›       at FunctionsRegistry.registerFunction (file:///usr/local/lib/node_modules/netlify-cli/src/lib/functions/registry.js:321:39)
 ›       at async file:///usr/local/lib/node_modules/netlify-cli/src/lib/functions/registry.js:423:13
 ›       at async Promise.all (index 27)
 ›       at async FunctionsRegistry.scan (file:///usr/local/lib/node_modules/netlify-cli/src/lib/functions/registry.js:386:32)
 ›       at async startFunctionsServer (file:///usr/local/lib/node_modules/netlify-cli/src/lib/functions/server.js:274:5)
 ›       at async (file:///usr/local/lib/node_modules/netlify-cli/src/commands/dev/dev.js:126:31)
 ›       at async BaseCommand.parseAsync (/usr/local/lib/node_modules/netlify-cli/node_modules/commander/lib/command.js:935:5)
 ›       at async file:///usr/local/lib/node_modules/netlify-cli/bin/run.js:27:3

I dove into the code and changed it from this (I added the arrow with ‘culprit’ for clarity):

func.buildData = {
                routes: manifestEntry.routes,  <--- culprit

To this:

func.buildData = {
                routes: manifestEntry?.routes,

The CLI no longer crashes, and my React app launches like before.

My question is, should I somehow add mainfest.json files to my project? Is it because I forgot some options? Or is this just a small bug?

Hi @patrizz , welcome to the Netlify Support Forums.

The syntax manifestEntry?.routes is using the optional chaining operator (?.). This operator allows you to access properties of an object even if the object is null or undefined. If manifestEntry is null or undefined, the expression manifestEntry?.routes will evaluate to undefined without causing a crash.

Optionally you can also add the manifest.json file and import it into the code.


@clarnx, can you please clarify:

Is it Netlify’s recommendation that I (the user) edit line 307 of registry.js from:


I have a repo on two machines where ONE shows the error reported by @patrizz, and the other does not. The only difference appears to be the version of netlify cli.

Has this been reported as an issue? Is a fix pending?

Considering this was reported once a month ago and once now, I don’t think this is a common issue. Mind sharing a reproduction so we can check it ourselves?

1 Like

I do mind, actually!

I’m not here to do Netlify’s work for free.


How about you go to this file in your own cli repo, then visit your so-called “test” suite for a laugh.

While you’re there, take note of the fact that your code coverage is abysmal.

Then, you’ll find that the offending lines of code here only handle the case where there is a manifest file. There is neither a unit test to check the happy paths for the manifestEntry object nor the most obvious failure mode (when manifestEntry is undefined).

You can then deduce from the information that @patrizz and I already graciously provided in this thread, that line 423 is an escaped defect. Without unit tests to reveal the defect before this code was pushed to production, you have adopted a policy by which your users become your f’n QA department.

So… maybe talk with your colleagues about learning some #TDD and up your quality before it’s too late.


I’ve opened an issue here. You’ll notice that the line I reference in the issue was committed 2 months ago — and in that same commit you will not find an associated test for the new line. (Is it Netlify’s official policy to not test their code? Please let the community know so we can all find a new host asap.)

Here’s a thought: when a user points out a defect in this forum, perhaps the response should be something like, “yea, we missed a test and we’ll fix it!” instead of “I don’t think it’s a common issue.”

Didn’t Boeing say the same thing? “We don’t think it’s a common issue.” As their airplanes were nose-diving into Earth at 850 miles per hour. And similarly, Boeing’s engineers simply hadn’t written a test for the case in which their MCAS sensor response was undefined.

Thank God Netlify is only building an HTTP service, not airplanes.

Hey @dns we are happy for lively participation in the Netlify Community - which is just that, a Community for folks excited about websites and using Netlify to build better websites. And Communities only work if people enjoy contributing.

However, in the post above you sound pretty angry, and we cannot accept you making our Community feel hostile with disrespectful comments like these. We’d appreciate it if you would refrain from this type of derisive language in the future.

As you have opened an issue on the cli repo, we’ll track progress on the issue there and I’ll close this post.

Thank you.

1 Like

Hi @laura,

I can see how you’d interpret my comments as angry — though the emotion I felt while writing it would be better described as vexation.


I was frustrated that, after @patrizz had already pointed out the offending lines of code and had shared detailed debug info, both @clarnx and @hrishikesh dismissed the fact that a defect exists in the cli.

I was annoyed that a suggestion had been made that someone (@patrizz or I, I presume) “share a reproduction” — this is the sort of thing a support engineer at Netlify can likely do in a few seconds (produce an environment using latest netlify-cli in a build that does not have a manifest) but it would take one of your customers/users perhaps half an hour to (1) produce, then (2) publish at GitHub, then (3) return to and share in this forum.

I was worried that code quality, which has been top-notch since 2018 (at least), appears to be suffering — given that large swaths of code are no longer covered by automated tests.


I’ll agree that my tone was derisive. (Good word.) But I think you misunderstand the word “disrespectful” — I pointed the support engineers to the offending lines of code and @patrizz even suggested a solution. I’d say that was very respectful of us both. (Though I cannot speak for @patrizz, we don’t even know each other.)

If you wish to close this post and delete my comments, that’s your prerogative — I’d even advise deleting my post if you think the community isn’t robust enough to encounter some challenging content.

But deleting the content won’t actually protect the community from hostility — it will only hide a quality problem in Netlify’s communication with its end users.

1 Like

Hi @laura,

I noticed the offending line of code is updated and the GitHub issue has been closed.

But the problem hasn’t really been resolved, has it?

I’ve left a comment at GitHub and I hope the engineers will think on it: This line breaks when manifestEntry is undefined · Issue #6348 · netlify/cli · GitHub