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
}
}
```
> Workspaces are a new way to setup your package architecture that’s available by default starting from Yarn 1.0. It allows you to setup multiple packages in such a way that you only need to run yarn install once to install all of them in a single pass.
- [x] Tested in development mode
- [x] Tested in production mode
- [x] Tested with deployment https://with-yarn-workspaces-hwzubdlkul.now.sh/
- [x] Added transpile module example
Closes#3638
Pulling out a few core points from the readme...
This example builds from /src into /dist, managing the different expectations of express.js (es5, commonjs) and next.js (es6) by using a pair of tsconfig.json files, both of which are run by `npm run build-ts` or any of the other npm targets.
Hot module reloading is largely but not completely wired up (nodemon is watching /dist but tsc isn't set up to watch /src and transpile changes in /src to /dist automatically (that's mainly because I wasn't sure how to start both nodemon and a pair of tsc watchers and be confident all would get shut down when the user killed dev mode). The readme suggests running `npm run build-ts` manually in another window to push changes from /src into /dev and on into the browser.
tslint is also wired up via `npm run tslint`
## Minor changes
When `NODE_ENV=test` is used we'll now apply the `'auto'` configuration for modules transformation. Which causes Babel to check if the current environment needs to be transformed or not. In practice this means that the following `.babelrc` is not needed anymore:
**OLD**:
```json
{
"env": {
"development": {
"presets": ["next/babel"]
},
"production": {
"presets": ["next/babel"]
},
"test": {
"presets": [["next/babel", { "preset-env": { "modules": "commonjs" } }]]
}
}
}
```
**NEW**:
```
{
"presets": ["next/babel"]
}
```
## Patches
`@babel/preset-react` has a `development` option that automatically applies a development-time plugin we manually applied before (`@babel/plugin-transform-react-jsx-source`). It also adds another development-time plugin that is said to make debugging/errors clearer: `@babel/plugin-transform-react-jsx-self` which we didn't apply before. Overall this means we can take advantage of preset-react to provide these plugins.
Currently, using `as` will cause the router to think the URL is not changing in the case where you're re-rendering the same page with a different route. This would most likely be an issue for custom servers
which are using shallow routing.
This should be an invisible change for non-custom-server users, since `as` is defaulted to `url` if not set.
This should resolve#3065.
The original example fails to compile on my windows machine but updating bs-platform fixes that.
Depending on bs-next causes example to fail (package compiled with old incompatible version of bs-platform) so I have included it in a bindings directory where it can serve as an example of reason bindings.
Sources have been migrated to the latest reason-react.
Fixes#5038
The problem with `constructor` is that it doesn't have `context` yet when being called. It's also considered unsafe to add a side-effect on constructor except when server-rendering
## Issue
Currently react-error-overlays launch-editor functionality doesn’t work because the module paths are in the wrong format.
## Todo
- [x] Keep source-maps enabled
## Related
https://github.com/zeit/next.js/pull/4979
~I am not sure if this is a valid fix yet, but I was going to let CI run the tests for me. I'll close and look into it if the build fails.~
Let me know if this will cause issues, but I don't think it should. The React docs recommends moving `componentWillMount` logic into the constructor
This PR:
* Removes dublicate `className` in: `<meta charSet="utf-8" class="next-head"/>`
* Refactores head reducer
Special thanks to @udanpe for reporting and @geoffRGWilliams for bringing me on the right tack! 🙌Closes#4745, #4802
