* Initial dev server
* Remove obsolete check
* Move hotReloader to dev-server
* Use parent renderErrorToHTML to remove dep on render.js
* Remove dev option from server itself
* show warning if there is a title in _document.js Head
* dont loop through children in production
* only 1 loop through this.props.children 💪
* also raise warning in test env
* check for null childs
- This makes sure the Next.js renderer / server doesn't have a dependency on the `http` module.
- Splits out util functions for SSR only
- Removes obsolete methods / methods that weren't being tree-shaken
* Add failing tests
* Upgrade wd module
* Pass dynamic import webpack ids to the client side
* Pass through webpack ids to initalializer and only use those
* Compile dynamic(import()) to dynamic(() => import())
* Default dynamicIds
* Use forked hard-source-plugin
* Possibly fix test
* Make tests fail less intermittently
* Temporarily disable hard-source in production
* Make sure dynamic import chunks are unique
* Disable hard-source
* Log html if error is thrown
* Fix test
* Add test for /_next/development route
* Make sure useFileSystemPublicRoute: false only disables filesystem routing
* Bring back comment
* Add useFileSystemPublicRoutes tests
@timneutkens
This simple change seems to work for me:
```
const ignored = [
'**/.*',
'node_modules'
]
```
I believe the regex is used here to try and work on windows as well. So, I wasted a bunch of time trying to figure out how to use a regex and/or the `path` module to ignore the parent directories until I noticed the following:
> glob patterns are not filepaths. They are a type of regular language that is converted to a JavaScript regular expression. Thus, when forward slashes are defined in a glob pattern, the resulting regular expression will match windows or POSIX path separators just fine.
this is from the [anymatch](https://github.com/micromatch/anymatch) documentation which is what webpack uses accoring to this:
https://webpack.js.org/configuration/watch/#watchoptions-ignored
I've verified this glob pattern solves the problem in my environment, can someone test and verify that this works on windows?
👍
Related #4659
Adds the possibility for users to copy files inside of `exportPathMap`. This allows for adding `robots.txt` `sitemap.xml` etc. another use case is for https://github.com/hanford/next-offline, currently it's manually reading the buildId in `exportPathMap`.
To allow users to do this we'll introduce a new parameter holding an object with the following keys:
- `dev` - `true` when `exportPathMap` is being called in development. `false` when running `next export`. In development `exportPathMap` is used to define routes and behavior like copying files is not required.
- `dir` - Absolute path to the project directory
- `outDir` - Absolute path to the `out` directory (configurable with `-o` or `--outdir`). When `dev` is `true` the value of `outDir` will be `null`.
- `distDir` - Absolute path to the `.next` directory (configurable using the `distDir` config key)
- `buildId` - The buildId the export is running for
Example usage:
```js
// next.config.js
const fs = require('fs')
const {join} = require('path')
const {promisify} = require('util')
const copyFile = promisify(fs.copyFile)
module.exports = {
exportPathMap: async function (defaultPathMap, {dev, dir, outDir, distDir, buildId}) {
if(dev) {
return defaultPathMap
}
// This will copy robots.txt from your project root into the out directory
await copyFile(join(dir, 'robots.txt'), join(outDir, 'robots.txt'))
return defaultPathMap
}
}
```
There's an edge case @timothyis is running into, this will show exactly what files are missing.
I currently can't reproduce, so this is a first step at providing better error messages
The current canary version shows the following warning in development mode:
```log
Warning: Each child in an array or iterator should have a unique "key" prop. See https://fb.me/react-warning-keys for more information.
in script
in NextScript
in body
in html
in Document
```
This PR adds proper keys to the devFiles on the server.
Related https://github.com/zeit/next.js/pull/4954
Depends on https://github.com/zeit/next-plugins/pull/228
Failing tests are expected as `@zeit/next-css` has to be updated/released first.
This implements rendering of `.css` chunks. Effectively removing the custom document requirement when adding next-css/sass/less/stylus.
* Compile pages to .next/static/<buildid>/pages/<page>
* Fix test
* Export class instead of using exports
* Use constant for static directory
* Add comment about what the middleware does
* Add support for custom App and Component enhancers
* Add ctx.renderPage test
* Add tests for single enhancer function
* Cleanup renderPage options check
* Cleanup
* Add comment about backwards compatibility for renderPage
* Add more test cases
This PR fixes#4615
From the issue :
> One thing we might consider is merging and showing a warning for keys not defined in exportPathMap
The behaviour after this PR is the following :
```js
// next.config.js
module.exports = {
exportPathMap: () => ({
'/': { page: '/', query: { a: 'blue' } }
})
}
```
| url called | `ctx.query` | warning ? |
|-|-|-|
| `/` | `{ a: 'blue' }` | |
| `/?a=red` | `{ a: 'blue' }` | |
| `/?b=green` | `{ a: 'blue', b: 'green' }` | `... parameter 'b' missing in exportPathMap` |
Is that the expected behaviour ? If not, I'll update the PR to shape the expected behavior.
I can't use a functional component with `_document.js`.
[is-react](https://www.npmjs.com/package/is-react) can be used for another potential implementation of the warning logic, but maybe relying on `React.createElement()` internal checks is enough.
A follow-up to #4604: the dot in the regexp was not escaped as intended. By default `*` matches greedily, so the results are the same, but the new regexp should be more clear. Sorry for the mistake.
The prepares for next-server.
I also took this as an opportunity to get all build directory paths from a single location, as they were previously scattered across webpack/babel plugins and loaders.
Fixes#4603.
Tests explain it the best:
```js
describe('development mode (no chunkhash)', () => {
it('should strip the extension from the filename', () => {
const filename = 'foo_bar_0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, true)).toBe('foo_bar_0123456789abcdef')
})
it('should only strip the extension even if there\'s a hyphen in the name', () => {
const filename = 'foo-bar-0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, true)).toBe('foo-bar-0123456789abcdef')
})
})
describe('production mode (with chunkhash)', () => {
it('should strip the hash from the filename', () => {
const filename = 'foo_bar_0123456789abcdef-0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, false)).toBe('foo_bar_0123456789abcdef')
})
it('should only strip the part after the last hyphen in the filename', () => {
const filename = 'foo-bar-0123456789abcdef-0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, false)).toBe('foo-bar-0123456789abcdef')
})
})
```
This fixes a missed bug introduced in #4510.
Because the regexp was `/-[^-]*/` and not `/-[^-]*$/`, a wrong part of the filename was being removed:
```
bad:
'foo-bar-0123456789abcdef-0123456789abcdef.js' -> 'foo-0123456789abcdef-0123456789abcdef.js'
good:
'foo-bar-0123456789abcdef-0123456789abcdef.js' -> 'foo-bar-0123456789abcdef'
```
By a stroke of luck this didn't affect the existing dynamically generated chunks. To prevent regression I've added unit tests for the function that generates the name.
Btw. in the original issue (#4433) I used the right regexp, I just used the wrong regexp in #4510.
cc @timneutkens
