Currently, `getBaseWebpackConfig` is marked async, but it doesn't await anything or otherwise return a Promise. Please correct me if I am wrong, but it looks like it can be made synchronous.
After talking with @timneutkens it was decided it'd be more streamlined to replace the onDemandEntries WebSocket with an alternative. Using the EventSource connection gives us these benefits over the WebSocket one:
- less code needed
- no extra server running
- no extra config for onDemandEntries
* fix(launch-editor): resolve filename including current working directory
* refactor: handle when fileName is already absolute
* feat: use Next.js dir instead of process.cwd()
Arguments that held the same name as one of the default commands were filtered out, causing issues.
For example `next build build` would get rid of the second `build` parameter.
Fixes#6263
Fixes#5347
The main issue is that we were waiting only 1 level of dynamic imports, so the dynamic imports nested inside other dynamic import files were not awaited. This would cause either a flash of loading states or you wouldn't see the loading state (because of preload) but it would then show a hydration warning in development.
Thanks to @arthens for providing the reproduction that I modelled the tests after.
* Remove usage of WebpackBar and Friendly Errors
* Add new clearConsole helper
* Add new simplified output for development mode
* Add an explicit bootstrapping mode
* Add missing returns
* Use existing output style
* Adjust first output to say Waiting on
* Only print URL if present
After discussion, I added falling back to fetch based pinging when the WebSocket fails to connect. I also added an example of how to proxy the onDemandEntries WebSocket when using a custom server. Fixes: #6296
Closes: #6244
This will block the following keys:
```
NODE_.+
__.+
```
There doesn't seem to be a way to simulate a failed build or else I'd add tests for it.
* Set default `Error` status code to 404
This is an appropriate default behavior because:
1. When the server encounters an error, the `err` property is set.
2. When the client-side application crashes, the `err` property is set.
This means the "only" way to render the `/_error` page without an error
is when a page is not found (special condition).
Fixes#6243Closes#5437
* Add new integration test for client side 404
* single quotes
* Remove unused variable
* Standard needs to go away
* Whoops
* Check for null status code in res and err
* Only check response for valid statusCode
* convert export default anonymous functions into named functions
* change examples to function declaration and split export in classes
* change NextHead name to Head and rename component
* Update README.md
I know I'm a moron for not understanding what's written in black on white, but... Maybe this will save someone an hour or two 😄
* Apply proposed changed
* Implement circular JSON err.sh link
* Add test for getInitialProps returning circular json
* Make test warn less
* Fix tests
* Add reference to original tests
Fixes#6117
I'm not entirely sure why we had this rule in the first place. I think for some tests related things when we didn't have a monorepo yet. However it could also be related to bundle sizes. I'll compare that when the build finishes.
The reason for #6117 is that we added `react-is` to the dependency tree of Next.js to check valid elements. react-redux uses hoist-non-react-statics which ships a different version of react-is in this case, one that has `ReactIs.isMemo`
Fixes#5363
I noticed this happening when making some changes on the nextjs.org/learn app. Basically we didn't apply updates when a warning was emitted from webpack. This would cause issues for users using eslint-loader or similar too.
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.
`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).
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.
This PR aims at replacing next-server/lib/event-emitter.js by mitt.
Fix https://github.com/zeit/next.js/issues/4908
event-emitter.js is ~400 bytes gzipped vs mitt is 200 bytes
Extends on #5927, instead of `.default` we'll expose `.render` which is semantically more correct / mirrors the naming of the custom server API.
I've updated the spec in #5927 to reflect this change.
(copied from #5927):
```js
const http = require('http')
const page = require('./.next/serverless/about.js')
const server = new http.Server((req, res) => page.render(req, res))
server.listen(3000, () => console.log('Listening on http://localhost:3000'))
```
Saw a reply on the original pull request that the WebSocket using a random port broke their set up so I added a `--websocket` or `-w` argument similar to the `-p` argument to allow manually setting this port also.
Fixes#5845
Implement tslint for core files
**What is this?**
Implements tslint for both next and next-server, but keeps standardjs/eslint for the .js files that are still there, we're gradually migrating to Typescript.
**How does it work?**
Before every commit (pre-commit) we execute the following `tslint` command:
`tslint -c tslint.json 'packages/**/*.ts`
**TSLint Rules**
In order to avoid as much changes as possible I marked some rules as false. This way we can improve the linter but making sure this step will not break things. (see tslint.json)
**Note**
After merging this PR, you'll need to update your dependencies since it adds tslint to package.json
**This does not change existing behavior.**
building to serverless is completely opt-in.
- Implements `target: 'serverless'` in `next.config.js`
- Removes `next build --lambdas` (was only available on next@canary so far)
This implements the concept of build targets. Currently there will be 2 build targets:
- server (This is the target that already existed / the default, no changes here)
- serverless (New target aimed at compiling pages to serverless handlers)
The serverless target will output a single file per `page` in the `pages` directory:
- `pages/index.js` => `.next/serverless/index.js`
- `pages/about.js` => `.next/serverless/about.js`
So what is inside `.next/serverless/about.js`? All the code needed to render that specific page. It has the Node.js `http.Server` request handler function signature:
```ts
(req: http.IncomingMessage, res: http.ServerResponse) => void
```
So how do you use it? Generally you **don't** want to use the below example, but for illustration purposes it's shown how the handler is called using a plain `http.Server`:
```js
const http = require('http')
// Note that `.default` is needed because the exported module is an esmodule
const handler = require('./.next/serverless/about.js').default
const server = new http.Server((req, res) => handler(req, res))
server.listen(3000, () => console.log('Listening on http://localhost:3000'))
```
Generally you'll upload this handler function to an external service like [Now v2](https://zeit.co/now-2), the `@now/next` builder will be updated to reflect these changes. This means that it'll be no longer neccesary for `@now/next` to do some of the guesswork in creating smaller handler functions. As Next.js will output the smallest possible serverless handler function automatically.
The function has 0 dependencies so no node_modules are required to run it, and is generally very small. 45Kb zipped is the baseline, but I'm sure we can make it even smaller in the future.
One important thing to note is that the function won't try to load `next.config.js`, so `publicRuntimeConfig` / `serverRuntimeConfig` are not supported. Reasons are outlined here: #5846
So to summarize:
- every page becomes a serverless function
- the serverless function has 0 dependencies (they're all inlined)
- "just" uses the `req` and `res` coming from Node.js
- opt-in using `target: 'serverless'` in `next.config.js`
- Does not load next.config.js when executing the function
TODO:
- [x] Compile next/dynamic / `import()` into the function file, so that no extra files have to be uploaded.
- [x] Setting `assetPrefix` at build time for serverless target
- [x] Support custom /_app
- [x] Support custom /_document
- [x] Support custom /_error
- [x] Add `next.config.js` property for `target`
Need discussion:
- [ ] Since the serverless target won't support `publicRuntimeConfig` / `serverRuntimeConfig` as they're runtime values. I think we should support build-time env var replacement with webpack.DefinePlugin or similar.
- [ ] Serving static files with the correct cache-control, as there is no static file serving in the serverless target
This brings us one step closer to outputting serverless functions as renderToHTML now renders the passed components, which allows us to bundle the renderToHTML function together with statically imported components in webpack.
Resolves#4055
Credit: https://github.com/zeit/next.js/pull/5095
I didn't use the ignore webpack plugin from the original PR and tested bundle size with https://github.com/zeit/next.js/pull/5339 - seems to be safe on that front.
Was able to get tests to pass locally, unsure of what goes wrong in CI 🤷♂️
**Questions**
1) The initial PR didn't include changes to `next-server/lib/router` in `getRouteInfo()`. Should the same changes be made within?
2) Should we add a test for rendering a component created via `forwardRef()`?
`component-with-forwardedRef`:
```javascript
export default React.forwardRef((props, ref) => <span {...props} forwardedRef={ref}>This is a component with a forwarded ref</span>);
```
some test:
```javascript
test('renders from forwardRef', async () => {
const $ = await get$('/component-with-forwardedRef')
const span = $('span')
expect(span.text()).toMatch(/This is a component with a forwarded ref/)
})
```
As I detailed in [this thread on Spectrum](https://spectrum.chat/?t=3df7b1fb-7331-4ca4-af35-d9a8b1cacb2c), the dev experience would be a lot nicer if the server started listening as soon as possible, before the slow initialization steps. That way, instead of manually polling the dev URL until the server's up (this can take a long time!), I can open it right away and the responses will be delivered when the dev server is done initializing.
This makes a few changes to the dev server:
* Move `HotReloader` creation to `prepare`. Ideally, more things (from the non-dev `Server`) would be moved to a later point as well, because creating `next({ ... })` is quite slow.
* In `run`, wait for a promise to resolve before doing anything. This promise automatically gets resolved whenever `prepare` finishes successfully.
And the `next dev` and `next start` scripts:
* Since we want to log that the server is ready/listening before the intensive build process kicks off, we return the app instance from `startServer` and the scripts call `app.prepare()`.
This should all be backwards compatible, including with all existing custom server recommendations that essentially say `app.prepare().then(listen)`. But now, we could make an even better recommendation: start listening right away, then call `app.prepare()` in the `listen` callback. Users would be free to make that change and get better DX.
Try it and I doubt you'll want to go back to the old way. :)
This message is from @timneutkens after making changes:
- Convert executables to Typescript
- Remove `minimist` in favor of `arg`
- Implement `--node-args` usage: `--node-args="--throw-deprecation"`
- Adds tests for usage of the `next` cli
Fixes#4495
Here's my approach for replacing the XHR on-demand-entries pinger #1364#4495. I'm not sure if this is the way everyone wants to accomplish this since I saw mention of using a separate server and port for the dynamic entries websocket, but thought this would be a fairly clean solution since it doesn't need that.
With this method the only change when using a custom server is you have to listen for the upgrade event and pass it to next.getRequestHandler(). Example:
```
const server = app.listen(port)
const handleRequest = next.getRequestHandler()
if(dev) {
server.on('upgrade', handleRequest)
}
```
# Fixes https://github.com/zeit/next.js/issues/5674
This adds config option
```js
// next.config.js
module.exports = {
crossOrigin: 'anonymous'
}
```
This config option is defined in the webpack Define Plugin at build.
`Head` and `NextScript` now use the config option, if it's not explicitly set on the element.
This value is now passed to Webpack so it can add it to scripts that it loads.
The value is now used in `PageLoader` (on the client) so it can add it to the scripts and links that it loads.
Using `<Head crossOrigin>` or `<NextScript crossOrigin>` is now deprecated.
* Convert render.js to typescript
* Compile tsx files too
* Remove internal renderErrorToHTML function
* Interopt component result
* requirePage doesn’t need async
* Move out enhancing logic into it’s own function
* Remove buildManifest from renderPage
* Move render into it’s own function
* Change let to const
* Move renderDocument into it’s own function
This PR will
- allow nextjs export to use all available CPU cores for rendering & writing pages by using child_process
- make use of async-sema to allow each thread to concurrently write multiple paths
- show a fancy progress bar while processing pages (with non-TTY fallback for CI web consoles)
The performance gain for my MacBook with 4 CPU cores went from ~25 pages per second to ~75 pages per second. Beefy CI machines with lots of cores should profit even more.
This PR Fixes#4920
So the problem is that when a next.js application is built on windows, the `pages-manifest.json` file is created with backslashes. If this built application is deployed to a linux hosting enviroment, the server will fail when trying to load the modules.
```
Error: Cannot find module '/user_code/next/server/bundles\pages\index.js
```
My simple solution is to modify the `pages-manifest.json` to always use linux separator (`/`), then also
modify `server/require.js` to, when requiring page, replace any separator (`\` or `/`) with current platform-specific file separator (`require('path').sep`).
The fix in `server/require.js` would be sufficient, but my opinion is that having some cross-platform consistency is nice.
This change was tested by bulding an application in windows and running it in linux and windows, aswell as building an application in linux and running it in linux and windows. The related tests was also run.
# Conflicts:
# test/integration/production/test/index.test.js
* Move send-html function and rewrite in typescript
* Move getPageFiles and convert to ts
* Move getPageFiles and convert to ts (#5841)
* Move getPageFiles and convert to ts
# Conflicts:
# packages/next-server/server/render.js
* Fix unit tests
We don't have to check if the file already exists here, since it's always in production mode (dev overrides the readBuildId method to always be `development`) If the file is not found (error is thrown) we check if the file exists. If not we throw a helpful error. In other cases we throw the original error.
Fixes#3705Fixes#4656
- No longer automatically dedupe certain tags. Only the ones we know are *never* going to be duplicate like charSet, title etc.
- Fix `key=""` behavior, making sure that if a unique key is provided tags are deduped based on that.
For example:
```jsx
<meta property='fb:pages' content='one'>
<meta property='fb:pages' content='two'>
```
Would currently cause
```jsx
<meta property='fb:pages' content='two'>
```
### After this change:
```jsx
<meta property='fb:pages' content='one'>
<meta property='fb:pages' content='two'>
```
Then if you use next/head multiple times / want to be able to override:
```jsx
<meta property='fb:pages' content='one' key="not-unique-key">
<meta property='fb:pages' content='two' key="not-unique-key">
```
Would cause:
```jsx
<meta property='fb:pages' content='two'>
```
As `key` gets deduped correctly after this PR, similar to how React itself works.
- Replaces taskr-babel with taskr-typescript for the `next` package
- Makes sure Node 8+ is used, no unneeded transpilation
- Compile Next.js client side files through babel the same way pages are
- Compile Next.js client side files to esmodules, not commonjs, so that tree shaking works.
- Move error-debug.js out of next-server as it's only used/require in development
- Drop ansi-html as dependency from next-server
- Make next/link esmodule (for tree-shaking)
- Make next/router esmodule (for tree-shaking)
- add typescript compilation to next-server
- Remove last remains of Flow
- Move hoist-non-react-statics to next, out of next-server
- Move htmlescape to next, out of next-server
- Remove runtime-corejs2 from next-server
* Remove flow-typed
* Remove flow types
* Remove the last types
* Bring back taskr dependency
* Revert "Bring back taskr dependency"
This reverts commit 38cb95d7274d63fe63c6ac3c95ca358a28c17895.
* Bring back preset-flow as it’s used for tests
* Revert "Revert "Bring back taskr dependency""
This reverts commit b4c933ef133f4039f544fb10bf31d5c95d3b27a2.
Extracting the logic that defines if a page is blocked to utils.
If that refactor make sense, I will create a next PR to cover both of the functions inside utils with tests.
* Add node_modules bundling under the —lambdas flag for next build
* Run minifier when lambdas mode is enabled
* Add lambdas option to next.config.js
* Add test for lambdas option
Takes advantage of caching between builds for Terser, also makes writing caches for babel-loader faster by disabling compression.
Results for zeit.co (350 pages):
Without cache:
[4:16:22 PM] Compiled server in 1m
[4:16:57 PM] Compiled client in 2m
✨ Done in 125.83s.
With cache:
[4:19:38 PM] Compiled client in 17s
[4:19:50 PM] Compiled server in 29s
✨ Done in 31.79s.
Note: these results are from my multi-core Macbook Pro 2017, exact specs:
MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports)
- 3,3 GHz Intel Core i5
- 16 GB 2133 MHz LPDDR3
- Intel Iris Plus Graphics 650 1536 MB
The `without cache` build runs uglify in parallel, so without cache is likely to take longer on environments where you have only 1 core available.
The `with cache` build however runs in a single thread, so the results should be similar.
