Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

I am building a wrapper middleware in express to restrict an entire next application from the public without a password and a username. It should catch every get request that's coming through, check for a logged-in boolean on a session found with an id from a session-cookie.

Current Behavior

It works as expected for every normal browser http get request, however it does not work for pages served through the next-router. I noticed this because I had reused a logo component on the restriction page which simply linked to '/' and even though the request went through the middleware and the correct code was run (basic if else with a logged-in boolean) it did serve the homepage.

Steps to Reproduce (for bugs)

const express = require('express')
const next = require('next')

const app = next({
dir: '.',
dev: process.env.NODE_ENV !== 'PRODUCTION'
})

const handle = app.getRequestHandler()
const server = express()

/* HARDCODED VALIDATE BOOLEAN */
const authenticated = false

app.prepare()

.then(() => {
/*
Page restriction middleware
*/
server.get('*', (req, res) => {
console.log(req.path)
if (!authenticated) {
console.log('Not authenticated.')
return app.render(req, res, '/restriction')
} else {
console.log('Authenticated.')
return handle(req, res)
}

})

const PORT = process.env.PORT || process.env.port || 3000
server.listen(PORT)

})

This code should never log 'Authenticated' much less actually serve the requested resource right?

Here's the thing, it never logs 'Authenticated' but it does serve any page you want if it was requested with next/link.

Front-end to reproduce:

index.js

export default () =>
<div>Restricted page. You cant see this without bypassing the express routing middleware.</div>

restriction.js

import Link from 'next/link'
export default () =>
<Link href="/"><button>I am the magic resctriction bypasser.</button></Link>

What's sort of funny about this is that you can click on that Link in the restriction page and then refresh the page and the middleware will render the restriction page again.

Issue 2:
When using docker build . on our production server, I get the following error:

...
Step 12/14 : RUN yarn build
---> Running in 95abf61028ab
yarn run v1.3.2
$ next build
> Using external babel configuration
> Location: "/usr/src/app/.babelrc"
> Using external babel configuration
> Location: "/usr/src/app/.babelrc"
> Using external babel configuration
> Location: "/usr/src/app/.babelrc"
> Using external babel configuration
> Location: "/usr/src/app/.babelrc"
> Failed to build
{ Error: (client) ./app/src/styles/pages/marketing.scss
Module build failed: ModuleBuildError: Module build failed:
#react-nav-root {
^
Invalid CSS after " if": expected "{", was "(module.hot) {"
...

Above, yarn build points to next build.

When docker is building the image, it generates the node_modules dir from scratch (dir is not present when pulling from github repo).

Notice how "Using external babel configuration" is repeated four times, and that there is no mention of using a webpack config. I use a css/scss loader in my next.config.js, and it looks like that file is not getting loaded, which is why it can't parse this scss file. A successful build locally (using docker build . with node_modules dir present) looks like this:

...
Step 12/14 : RUN yarn build
---> Running in b1d43e9221e8
yarn run v1.3.2
$ next build
> Using external babel configuration
> Location: "/usr/src/app/.babelrc"
> Using "webpack" config function defined in next.config.js.
Done in 77.93s.
...

Notice that it finds the webpack config no problem.

Here is my Dockerfile (some parts redacted):

FROM mhart/alpine-node:9.3.0

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Install app dependencies
COPY package.json /usr/src/app/
RUN yarn install

# Bundle app source
COPY . /usr/src/app

# build
RUN yarn build
EXPOSE 3000

CMD [ "yarn", "serve" ]

I believe the problem is due to #3119. Rolling back to next@4.2.0 solved the problem.

My fork, which is a copy of next@4.3.0-canary.1 with #3119 rolled back, also fixes the problem.

I have searched the issues of this repository and believe that this is not a duplicate.

Context

Building with next build works when I am developing locally and have my node_modules dir present. However, our production servers use docker to build our image. In my project, node_modules aren't checked in, they get recreated via yarn. Next is unable to locate it after yarn install, or does something very fishy. This has something to do with #3119 because reverting that change fixed the problem for me.

This is preventing us from deploying our app with the latest canary release.

Your Environment

Tech
Version

next
4.3.0-canary.1

node
8.9.1

OS
10.12.6