* 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
Since we are now using webpacks `mode` flag we can get rid of:
* `webpack.optimize.ModuleConcatenationPlugin`
* `webpack.DefinePlugin` (`process.env.NODE_ENV`)
https://webpack.js.org/concepts/mode/
* Add test for /_next/development route
* Make sure useFileSystemPublicRoute: false only disables filesystem routing
* Bring back comment
* Add useFileSystemPublicRoutes tests
## 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.
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
~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
- [x] Add unit test
- [x] Allow to get the display name of a native component (e.g.: `div`) without throwing
- [ ] Remove displayName in production mode
`<Container>` does not receive any property. There is no way the *scrollToHash* logic can work right now. I believe it's a regression. It was working fine at some point. I'm sorry, I'm too lazy to add a test.
This fix was tested on Material-UI 👌.
This bug reproduction is the following:
As soon as you want to transition to a new page with a hash. The scroll doesn't change.
- start on pageA
- you scrollTop to 100
- you move to pageB#hash
- you stay at scrollTop 100, but #hash is at scrollTop 400.
* Throw error if getInitialProps is defined as as instance method
Omitting the static keyword happens pretty often. Therefore we should trigger a warning in devmode.
Closes: #4782
* Document getInitialProps error
* Add unit tests for loadGetInitialProps
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
There are occasions where it is useful to have `target='_blank'` on hyperlinks within your own app. (For example, if your app is being loaded in an iframe and you'd like for the links to break out in to new windows.)
With this PR, the `onClick` logic in Link now checks for an external target on the nested <a/> tag, and will fall back to the default behavior if it's present, similar to the logic for shift-/cmd-clicking the link.
## What's wrong
This problem is specific to errors that happen on the client _after_ the initial mounting of the component. (The router has special logic to handle exceptions thrown in `getInitialProps` during a client-side navigation, and I've confirmed this logic is correct.)
Specifically, if the page is mounted, and you raise an exception on the page, the exception will cause the error page to be mounted without ever invoking `getInitialProps` on the new App/Error page pairing.
This has been illustrated with multiple repros in #4574.
## Why is it broken
This regression was introduced two months ago in #4156, where the invocation of `getInitialProps` was removed from the app's top-level error handler. Specifically, [this line](https://github.com/zeit/next.js/pull/4156/files#diff-895656aeaccff5d7c0f56a113ede9662L147) was removed and [replaced by a comment](https://github.com/zeit/next.js/pull/4156/files#diff-895656aeaccff5d7c0f56a113ede9662R167) that says that "`App` will handle the calling of `getInitialProps`".
I believe the sentiment about "`App` will handle calling `getInitialProps`" is mistaken. In fact, it really doesn't make sense on its face, since it would require an instance lifecycle method of `App` (which is mounted immediately after the comment) to invoke the `static getInitialProps` method on the error page.
## How I fixed it
I've fixed this in a fork by restoring Lines 146 – 148 that were removed in #4156. I think this is the right fix, but Next.js's handling of `getInitialProps` could certainly be improved. (The code in [this conditional](86d01706a6/client/index.js (L173)) speaks to the unnecessary complexity around this.)
When clicking a next/link with a hash (#something) multiple times, it wouldn't keep the scrolling behavior browsers have. This makes sure we correctly trigger it.
Fixes#4686
Adds tests for @zeit/next-typescript so that we don't regress on this again.
I've fixed an issue in the `next` CLI too which caused lingering processes when the process gets force killed, which is what we do in the test suite, so it kept running if there was no manual quit.
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.
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
resolves#4115
For now, I just added `'article:tag'` so it could be duplicated if we need more we have to extend:
```javascript
const ALLOWED_DUPLICATES = ['article:tag']
```
Previously we called this directory holding the pages/chunks for server rendering `.next/dist` instead of `.next/server` which is confusing both when looking at it and in the codebase, since there's also `distDir` as a configuration option.
Also made this a constant in `next/constants` so functionality using this can be easily found.
Allow `onClick` on `next/link` child. This should not be a breaking change, but it's a very useful feature. Real-life use cases include: analytics or closing menu on navigation, and other.
- [x] allow optional `onClick` on `next/link` component's child
- [x] call original `child.props.onClick(e)` before `this.linkClicked(e)`
- [x] add integration tests
- [x] cancel the navigation if `e.defaultPrevented === true`
Fixes#1490
* Don’t use chunkhash in development
* Add test for dynamic imports styling
* Remove pre-load of dynamic page
* Make sure the browser gets closed only once
Adds an example based off of @jthegedus work on firebase hosting, compatible with next v6 and using typescript in both the firebase functions and the next app.
* Handle production errors correctly
* Improved source map support
* Make react-hot-loader hold state again
* Remove console.log
* Load modules on demand
* Catch errors in rewriteErrorTrace
* Update comment
* Update comment
* Remove source-map-support
* Load modules in next-dev
* Make sure error logged has sourcemaps too
* Add tests for production runtime errors
* Add tests for development runtime errors. Fix issue with client side errors in development
* Move functionality back to renderError now that error handling is consistent
* Rename to applySourcemaps
* Expose pages/_app.js
* Add tests for _app and _document
* Uncomment deprecation warnings
* Add documentation for _app, improve documentation of _document
* Update docs / test for _document
* Add _document to client compiler in development
* Add missing app.js to comment
* Only warn once
* Add url-deprecated error page
* Combine tests
* Yse same message for all methods of ‘props.url’
* Update docs around _app
* Update documentation
* Quotes
* Update table of contents
* Add build manifest
* Split out css since they don’t have exact name
* Remove pages map
* Fix locations test
* Re-run tests
* Get consistent open ports
* Fix static tests
* Add comment about Cache-Control header
* Initial implementation of next export without exportPathMap
* Shorter message
* Set up flow
* Create pages manifest
* Use pagesManifest for next export
* Fix tests
* Document defaultPathMap
* Replacing the path is no longer needed
* Use posix normalize for consistent behaviour
* Remove second instance of examples
* Add comment about what pages-manifest does
* Make windows path a route
* Allow etags to be disabled with config option
- CR Change: Rename option to generateEtags
- CR Change: Add tests for etag generation
- CR Change: Refactor to use next.config.js
- Update documentation
* Use renderOpts instead of passing nextConfig
* Removed combine-assets-plugin, since its very broken
* Bundle everything into app.js on production build
* Clean up
* Removed app.js from server routes
* Renamed app.js -> main.js and removed commons from loading
* Remove commons and react CommonChunks
* Removed the commons route
* Killing the entire build-stats hack for app.js
* Removed unused md5-file package
* Add specific test cases for Error Recovery.
* Update hmr/about.js
* Add a test case: should recover after a bad return from the render function
* Add test case: should recover from errors in getInitialProps in client
* Add test case: should recover after an error reported via SSR
* Add a test case: should recover from 404 after a page has been added
* Refactor code base.
* Add next/config
* Set config on server start / client render
* Add documentation for next/config
* Add next/config support for next export
* Fix test
* Use the correct name
* Set default to empty object on the client side
* Add config tests
* Rename config to runtimeConfig
* Fix SSR error handling.
* Remove unwanted console.logs
* Fix a typo.
* Fix current tests.
* Add a new test case for this case.
* Error should only be logged if it is not a 404
* Allow next.config.js to export a function
* Expose phases to the configuration function
* Use same value as variable name
* Add next/constants
* Add documentation for config function / phases
* Add constants.js to npm bundle
* Add custom-server-typescript example (see #3694)
* Fix linting errors in custom-server-typescript
* Provide proper arguments to ts-node.
* Fix import and fix all linting errors.
* Use import in server as well.
* Update nodemon.json
* Remove special error script handling.
As a result of that, we can't detect 500 errors and buildIdMismatch via client side.
* Fix failing test cases.
* Refactor the code base.
* Remove Router.onAppUpdated
This reverts `fb7c862` per @timneutkens
- Removes the errors/*.md associated
- Puts back `poweredByHeader` for `next.config.js`
- Reincorporates test:
X-Powered-By header
✓ should set it by default (3ms)
✓ should not set it when poweredByHeader==false (5ms)
Also tested with `yarn link` and verified.
* Make page require faster
* Add windows search/replace
* Use normalize instead of resolve
* Add remaining tests
* Use sep instead of /
* Add test files
* Make component require faster
* Add console.error
* Make pageExtensions configurable
* Remove resolve.js
* Add test for `.jsx`
* Also resolve `/nav/index` and the likes
* Normalize page paths
* Use config passed off by webpack
* Render error on the client without fetching additional scripts.
* Fix test cases.
* Remove unused '_document' page in ensurePage logic
* Remove console.error when page is not found
* Make page require faster
* Add windows search/replace
* Use normalize instead of resolve
* Add remaining tests
* Use sep instead of /
* Add test files
* Make component require faster
* Add console.error
* Add example on how to pass data through js api during SSR
Requested in #1117
* Use content negotiation instead of a separate route
* Codereview feedback
* Move security related test cases into a its own file.
* Removes the unused renderScript function
* Add a nerv example. (#3573)
* Add a nerv example.
* Fix for indentation/style
* Fix for name
* Allow next/asset to work properly with dynamic assetPrefix
Now we use webpack's publicPath via client side.
* Add test cases for dynamic assetPrefix and next/asset.
