* Get all modules included in build
* Add tests
* Get all modules contained per entry chunk
* Sort files
* Add specialized page entry to manifest
* Split manifest into pages and chunks key
* Update test
* Use relative paths to build directory
* Update test
* Added amp-toolbox-optimizer and added
optimizing AMP pages as dirty and clean
* Fix amp-optimizer breaking serverless build
* Exclude amp-toolbox-optimizer from serverless build
* Added check to make sure hybrid AMP pages
optimize cleanly during export
* Add check to make sure noDirtyAmp is applied
* Added a check for ad_ in the buildId
* ad_ > ad
Co-Authored-By: lfades <luis@zeit.co>
* Update the `ad` comment
Co-Authored-By: lfades <luis@zeit.co>
* Avoid all buildId's that contain "ad"
Looking through the uBlock Origin filter list, it uses regex wildcards to avoid various things with "ad" anywhere in the string. It's a safe bet to just avoid "ad" all together (as opposed to just at the start).
* Use regex (case incensitive) to check for "ad"
The following cases will set this regex to true:
```
/ad/i.test("somead")
/ad/i.test("someADlksdjf")
/ad/i.test("adlksdjf")
/ad/i.test("ADlksdjf")
```
* Added a check for ad_ in the buildId
* ad_ > ad
Co-Authored-By: lfades <luis@zeit.co>
* Update the `ad` comment
Co-Authored-By: lfades <luis@zeit.co>
* Add err.sh link and pool validation results
to wait to show error until export is finished
* Fix wording in amp-export-validation err.sh
* Update validation error message
Co-Authored-By: ijjk <22380829+ijjk@users.noreply.github.com>
* Update ways to fix text
Co-Authored-By: ijjk <22380829+ijjk@users.noreply.github.com>
* Update why the error occurred wording
Co-Authored-By: ijjk <22380829+ijjk@users.noreply.github.com>
* Update wording some more
Co-Authored-By: ijjk <22380829+ijjk@users.noreply.github.com>
* [WIP] Use a shared module cache
* ID modules in development
* Revert "ID modules in development"
This reverts commit 0613d92fa2c8c7fa11a5ff5b7770d784af1cec63.
* Remove context replacement
* Only enable shared runtime in prod
* Sort settings
* Add shared runtime experimental setting
* only enable shared runtime in serverless
* Simplify getDisplayName
* Don’t use array for single file
* Add aliases, drop htmlescape as it’s not longer in the codebase
* Add correct path
* Use the correct router
* Remove dynamic for now
* Mark as external as the modules are directly called
* Add comment explaining what this does
When overriding `config.resolve.alias` incorrectly webpack will throw an error because private-next-pages is not defined. This adds a more descriptive error explaining the error better.
Fixes: #6681
By default when `next export`ing a Next.js application we will automatically append a `/` to all urls to be fully compatible with the directory structure being output.
However since most platforms support directory indexes it makes sense to change this default in the future.
This PR adds `exportTrailingSlash` as experimental flag. We'll try this out for a bit on nextjs.org / zeit.co/docs before introducing it as new option.
The default value is `true` as this is the current behavior in stable Next.js.
```
{
experimental: {
exportTrailingSlash: false
}
}
```
⚠️ as with all experimental flags being added this is subject to breaking between canary/stable versions.
* Add a new field to webpack types
* Revert "Add a new field to webpack types"
This reverts commit d35fa02207fbfd0085da0fc56aac42c4ff7c34c9.
* Add HashedChunkIdsPlugin to make consistent chunk ids
* Revert "Revert "Add a new field to webpack types""
This reverts commit 338219049e1432038f90c91928b010bbb1267999.
* Make it optional
* Remove record ids
* Revert "Remove record ids"
This reverts commit 15c22dbcda72466c382397c91d02295620f62326.
When the webpack `mode` is set to `production`, `minimizer: undefined` means "use the default webpack minifier."
We need to explicitly disable the webpack minifier via `minimize: false`. This should speed up non-serverless builds. 😄
This doesn't affect dev, but I added the toggle there for consistency.
### changes
#### remove trailing spaces
When I was using example I noticed trailing spaces.
So, this PR removes the trailing spaces of json file, README, and others.
`examples/with-jest-typescript/src/modules/cars/Overview.tsx` also has it, but this time it did not change as tslint error occurs at commit.
After discussion it was decided instead of rewriting `next/config` and `next/head` imports to `next-server/config` and `next-server/head` we should just allow importing them as `next/config` and `next/head`
Fixes: #6187
We don't use a lot of the features of `glob`, so let's remove it in favor of a leaner approach using regex.
It's failing on windows and I have no idea why and don't own a windows machine 🤦🏼♂️
(Ignore some of the commits in here, I forgot to create the new branch before I started working)
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.
* 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
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.
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`
`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).
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.
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.
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'))
```
**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
# 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.
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
- 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.
* 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.
Clears the way a bit for #4943, also makes _document.js less complex, and will allow us to move `__NEXT_DATA__` to a `application/json` script tag.
Also this causes a slightly smaller bundle size 😌
- Shows warnings even when resolving, to facilitate hints set to 'warning'
- Fixes#876 : Set performance.hints to 'warning' or 'error' in next.config.js
* 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())
