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

Expected Behavior

All styled-components with their CSS attributes applied

Current Behavior

All styled-components have their CSS class name, but, for any reason, some styled-components don't have their CSS attributes, then their styles will not be applied

Steps to Reproduce (for bugs)

Enter to Testing site

In this first page, the styled-components is ok, but in the second page exist the problem

In the search input type: "Las Condes"

Internally I redirect with:

Router.push({
pathname: '/results',
{ page: 1, lat: -33.3989812, lng: -70.5573124, operation: 'arriendo' },
});

In the Results page, the rigth component style is wrong:

And the login modal buttons is ok:

If reload the results page, (for a unkwnow reason) the right component is ok, but modal login button is wrong.

Context

In my development environment all works. But after of the build the code (next build) the problem happens

Your Environment

Tech
Version

next
^4.1.4

node
7

OS
Linux

browser
Chrome

styled-components
^2.2.4

Issue 2:
Moving forward, it will be possible to substitute next start in your programs with your own script, initialized without any wrappers. For example, node index.js.

An example of such a script in its most basic form would be as follows:

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

// init next
const app = next(/* __dirname */)
const handle = app.getRequestHandler()

// init normal http server
createServer(handle).listen(3000)

This basically does nothing interesting, it's the equivalent of next -p 3000.

An important observation: notice that the parameter passed to next() to initialize the app is not a config object, but a path. This is because the configuration will be conventionally located in a next.config.js file where a next project lives. Credit goes to @Compulves (#222) for this great contribution.

This is crucial because even though we get to substitute the server code, we don't break existing and future useful next sub-commands. Especially next build, which makes deployment to production of your next apps so convenient, continues to work well even with both node server.js and next start.

Custom routing

Next.js's pages/ serves two purposes: to give you a super easy-to-use API for defining routes, but more importantly, to define different entry points for code splitting!

I say more importantly because it should be (and will be) possible to completely override the default route mapping, by invoking next/render manually.

The following example shows how you could point /a to pages/b.js and /b to pages/a.js, effectively changing the default routing behavior

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

// init next
const app = next(/* __dirname */)
const handle = app.getRequestHandler()

// init normal http server
createServer((req, res) => {
const { query, pathname } = parse(req.url, true)
if ('/a' === pathname) {
render(app, res, 'b', qry)
} else if ('/b' === pathname) {
render(app, req, res, 'a', query)
} else {
handle(req, res)
}
}).listen(3000)

In addition to the render method, we'll expose lower level render APIs, like renderToHTML and renderError, which work like render but don't do the automatic response handling. Those APIs are useful for building a caching layer, for example, which is really handy if you know that a certain component will always return the same HTML with given props.

More complicated routes like /posts/:id/tags or even /:anything can be handled by just parsing the URL and passing the appropriate props as the last parameter of render (as seen in the example), by using something like path-match

This is an example of how you do a catch all route, so that every request to /catch/* goes to a page pages/my/page.js:

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

// init next
const app = next(/* __dirname */)
const handle = app.getRequestHandler()

// set up routes
const match = require('path-match')()
const route = match('/catch/:all')

// init normal http server
createServer((req, res) => {
const { query, pathname } = parse(req.url, true)
const params = match(pathname);
if (false === params) {
// handle it with default next behavior
handle(req, res)
} else {
// renders `pages/my/page.js`
render(app, req, res, 'my/page', query)
}
}).listen(3000)

The idea here is that we retain the smallest possible API surface, minimize the number of dependencies you have to install and code to evaluate.

Fancy routing approaches vary widely, and we don't want to lock you in to a particular one. It should be entirely possible to implement express instead of http.createServer, for example.