There's still a few Typescript helpers in use, but regenerator is added by Babel after this change, as it was already in the bundle it'll drop bundle sizes by quite a bit, eg _app.js becomes half the size.
RE: https://github.com/zeit/next.js/issues/4587, this pull request improves the with-segment example.
Previously, only SSR page loads were tracked. This pull request adds manual page view logging via `Router.events.on('routeChangeComplete')` in `Page.js`.
There is also a minor bug fix on the textarea to remove a console error.
`react-is` isn't used in production, so we shouldn't bundle it.
Note: most of those plugins are using the `dev` variable, but in case someone runs `NODE_ENV=development next build`, they would need a copy of `react-is` because the conditional use of `react-is` checks `NODE_ENV` — not whether or not HMR is being used (what what the `dev` variable is based on).
…aces (home and about pages). This makes it the example more clear and why someone might want to use _app.js in the first place. Also, added a button on the about page that allows for passing and arbitrary value from the about page to the context provider. I disagree with the naming convention of calling the class CounterProvider. It includes both a Provider and Consumer so it should have some name that covers both. Maybe it should be called CounterContext but I did not change that. I've seen other examples of the same naming conversion so figure I'm the odd duck here (still think it's wrong no matter how many people do it).
Adds a Bullet Point under "Production deployment"
for the Table of Contens / Link Section.
Wanted to add this as a comment in #6070.
Great work as always!
Introduces full support for Babel 7 including JSX Fragments shorthand.
Switched to visiting the `Program` path and then start a traversal manually to solve conflicts with other Babel plugins.
Fixes https://github.com/zeit/now-builders/issues/168
For some reason with a certain mix of deps `...` is not supported in webpack's parsing.
By default it is supported as all our tests passed before and we have deployed Next.js apps on v2 already.
original code in `/lib/router/router.js`
```
urlIsNew (pathname, query) {
return this.pathname !== pathname || !shallowEquals(query, this.query)
}
```
the urlIsNew compare `this.pathname` to an argument `pathname`
the invokers:
```
// If asked to change the current URL we should reload the current page
// (not location.reload() but reload getInitialProps and other Next.js stuffs)
// We also need to set the method = replaceState always
// as this should not go into the history (That's how browsers work)
if (!this.urlIsNew(asPathname, asQuery)) {
method = 'replaceState'
}
```
the parameter here is `asPathname` destructured from `asPath`
so here is a problem when we reuse a single page rendered in two asPaths
pages/a.js
```
<>
<Link href='/a'><a>goto a</a></Link>
<Link href='/a' as='/b'><a>goto b</a></Link>
</>
```
If we navigate to page /a, then click 'goto b', actually the history is replaced, not pushed.
It is expected that history could be correctly pushed and popped as long as the browser url is changed.
It’s an inconsistent result, users should use ctx instead. At a later time we’ll normalize the properties passed into _app.js its getInitialprops to be consistent with pages.
This PR fixes the buggy `Head.propTypes` here:
https://github.com/zeit/next.js/blob/v8.0.0-canary.3/packages/next-server/lib/head.js#L107
Currently, `Head.propTypes` allows one child node like this:
```jsx
import Head from 'next/head'
// …
<Head>
<title>Title</title>
</Head>
```
But more than one child node mistakenly causes a prop type error like this:
```jsx
<Head>
<title>Title</title>
<meta name="description" content="Description." />
</Head>
```
```
Warning: Failed prop type: Invalid prop `children` supplied to `Head`.
```
It looks like :
```
Pages sizes after gzip:
┌ / (196 B)
├ /_app (11.5 kB)
├ /_error (4.44 kB)
├ /blog (196 B)
└ /blog/page (195 B)
```
(style inspired from now-cli : https://github.com/zeit/now-cli/blob/canary/src/util/output/builds.js)
I'll add dynamic chunks in a separate PR.
@timneutkens Do you want to keep `_app` and `_error` or filter them out ? I think it's a good idea to keep them, because `_app` can get pretty large and it would encourage code splitting in that case.
I wrote a [script](https://github.com/j0lv3r4/dependency-version-updater) to update dependencies recursively in `package.json` files, e.g.:
```
$ node index.js --path="./examples" --dependencies="react=^16.7.0,react-dom=^16.7.0"
```
This PR contains the result against the examples folder.
I changed the version to the following files:
- [x] - examples/with-next-css/package.json
- [x] - examples/with-draft-js/package.json
- [x] - examples/custom-server-polka/package.json
- [x] - examples/with-cerebral/package.json
- [x] - examples/with-zones/package.json
- [x] - examples/with-universal-configuration-runtime/package.json
- [x] - examples/with-apollo/package.json
- [x] - examples/with-higher-order-component/package.json
- [x] - examples/with-hashed-statics/package.json
- [x] - examples/with-pkg/package.json
- [x] - examples/with-jest/package.json
- [x] - examples/with-glamorous/package.json
- [x] - examples/with-custom-reverse-proxy/package.json
- [ ] - examples/with-emotion/package.json
- [x] - examples/with-styled-jsx-scss/package.json
- [x] - examples/with-styled-jsx-plugins/package.json
`with-emotion/package.json` already has the latest, so I guess it's other packabe. BUT I think we need to update this example with the latest version of `emotion` since it changed a little bit (for better).
