* Update jest
* Let jest start chromedriver
This makes sure chromedriver always ends even if the test was canceled by the user.
* Properly close browser in production-config test
* Properly close browser in production/security test
* Properly close browser in export test
* Properly close browser in app-aspath test
* Remove taskr from project root
This isn’t needed anymore
* Readd taskr to project root (temporary)
* Improve global setup/teardown
* Properly close browser in basic/client-navigation test
Clicking an target=_blank link will open a second browser window. We can only close this by using broser.quit()
* Set a default path for wasm modules
* Added the mimetype "application/wasm" for wasm files
* Upgrade write-file-webpack-plugin to 4.4.1
* Made dynamic(import()) in test to dynamic(() => import())
* 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
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
`<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.
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.
