Next.js: TypeError: Cannot read property 'amp' of null

[zomars]

When upgrading from next 8.0.3 to 8.1.0 I get the following error when compiling any page:

 [ error ] TypeError: Cannot read property 'amp' of null
     at Object.renderToHTML (/usr/app/enrola-webapp/node_modules/next-server/dist/server/render.js:169:33)
     at process._tickCallback (internal/process/next_tick.js:68:7)

[zomars]

I'm not using AMP at all BTW. And I couldn't find any breaking changes warnings or upgrading guides anywhere. Any guidance is appreciated 🙏

[nblthree]

A reproduction is necessary.

[timneutkens]

I wonder why the issue template was ignored.

[zomars]

It wasn't ignored. It just didn't add any more context to the issue. All I did was to upgrade from 8.0.3 to 8.1.0 and the error appeared. I reverted back and it dissappeared.

[timneutkens]

It wasn't ignored.

There's nothing from the issue template in the issue description. See: https://github.com/zeit/next.js/issues/new/choose

It asks for everything needed to make an issue actionable, as currently we can't take a look into it as it's impossible to reproduce "upgrade":

Bug report

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: [e.g. macOS, Windows]
• Browser (if applies) [e.g. chrome, safari]
• Version of Next.js: [e.g. 6.0.2]

Additional context

Add any other context about the problem here.

[elmasse]

To add my 2 cents in here, I had the same issue with 8.1.0 and 9.x the root cause I found in my case was that url.parse returns the urlObject with query=null. Then any default value passed as ( query = {} ) was not defaulted to {} and then the check of query.amp in 9.x throws.

In my case I have a custom server, so it's quite simple to fix it by just checking for null and making the default to {}.

Not sure thou how to reproduce this in a plain example.

[zomars]

In my case I solved like this:

const { createServer } = require('http')
const { parse } = require('url')
const next = require('next')

const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {
  createServer((req, res) => {
    // Be sure to pass `true` as the second argument to `url.parse`.
    // This tells it to parse the query portion of the URL.
    const parsedUrl = parse(req.url, true) // <---- I DIDN'T PASS TRUE HERE
    const { pathname, query } = parsedUrl

    handle(req, res, parsedUrl)
  }).listen(3000, err => {
    if (err) throw err
    console.log('> Ready on http://localhost:3000')
  })
})

[elmasse]

Arrggh, you are absolutely right. I changed the url.parse to new URL because I had standard complaining with deprecated methods and I forgot to add back the second parameter. Jeez!!!!!!

[zomars]

IKR! It took me months... 😢

[jorgeorpinel]

This is still happening to me right now on next 9.1.6... Using workaround mentioned in https://github.com/zeit/next.js/issues/7303#issuecomment-511053550 above (check for null in the query prop of the object returned by url.parse and change it to {}) because I actually don't want to pass true as the 2nd param of url.parse (parseQueryString).

I think Next.js should check this on their end, supporting url.parse without parseQueryString = true (resulting in query === null) though...