* Throw Error for next.config.ts
Ref: https://github.com/zeit/next-plugins/issues/555
* Check for .js else .ts
* Update Error Message
Co-Authored-By: Alexander Kachkaev <alexander@kachkaev.ru>
* Add test case when both next.config.js and next.config.ts exist.
* Remove extra constant CONFIG_FILE_TS and Add check for ts/tsx/json
* Rename test config parameter and add tsx and json files
* Change messege
* change value
* Update next.config.json
* Update next.config.json
* Change message and add jsx filter
* Adjust
* Simplify test
* adjust
* Improve serverless build performance
Next's serverless build uses a custom resolver, injected the via Webpack's `externals` option that delegates out to `resolve-request` to more aggressively pull node modules into the serverless bundles.
When profiling a large Next.js application, I noticed an excessive number of filesystem calls near the end of the build. I narrowed this down to the serverless compiler pass, and eventually the custom resolver function that is the subject of this PR. As it turns out, around half of the calls to the `externals` custom resolver function are for a `request` path that is a relative import. Next doesn't have any specific logic to apply to relative imports - it only needs to special-case bare module resolution.
Adding a simple bypass for relative module resolution reduces the number of blocking filesystem-bound `resolveRequest()` calls by 50% on a certain well-known Next.js website. This also results in a 30% reduction in production build times for incremental builds.
* Explain more in the comment
* Enable granular chunks config for all chunk types
Adding comment
Bug fix
* Update index.test.js
* Update index.test.js
* Fix test cases. Adding next/link to not trigger a different bug
* Removing obsolete comment
* Pass config.experimental.cpus to export during build
Currently, there is no way of specifying the number of worker threads of
`next export` when run as part of `next build`.
I suggest a sane default should be to just use the same amount of
workers that were used during the build process which currently seems to
be configured through `config.experimental.cpus`.
This setting is already respected in the two other places where
jest-workers are in use: The TerserPlugin and the staticCheckWorkers in
`next build`.
* Only enable worker threads if there is more than 1 worker
Multiple worker threads can cause problems when certain dependencies are
being used, see e.g. https://github.com/zeit/next.js/issues/7894
This patch allows disabling of worker threads by setting
`config.experimental.cpus = 1`.
The benefit of spawning 1 worker thread, if there is any at all, should
very limited anyways, so the workload can just as well be processed in
the main thread.
* Disable parallel build for firebase authentication example
* Add integration test to cover #7894
* Rename test suite and add worker_threads config
* Disable worker_threads by default
* Update index.test.js
* Use workerThreads config for TerserPlugin
* Update to use workerThreads config in
TerserPlugin for consistency
* Disable node 12 specific test
* Add a configuration flag to disable integrated type checker
* Add tests for typescript-transpileonly
* Restore removed argument
* Make output more coherent
* Split transpileOnly into ignoreDevErrors and ignoreBuildErrors
* Minor stylistic change
* Add warning for getStaticParams without getStaticProps
* Throw error instead of logging to make sure it's noticed
* Lower default concurrency for tests
* allow NextScript to optionally defer javascript
* move defer options to experimental feature
* combine defer flags into a single option
* Update deferScripts to work with serverless target
* Add test for defer and async property
* Read the async property
* Check versions of chrome and chromedriver
* Update to chromedriver 76
* Fix test
Before this patch users would see the following warning during initial
compilation:
```
Warning: Each child in a list should have a unique "key" prop. See https://fb.me/react-warning-keys for more information.
in link
in Head
in html
in Html
in Document
in Context.Provider
in Context.Provider
```
* Ensure directory before flushing cache iSSG file
* Add test for prerender cache flush
* Nest the dynamic route test one more level
* update fetch for test
* Update error check
* Add tracking src dir usage to telemetry
* Move isSrcDir back to eventVersion
* Move spinner back
* Add test for isSrcDir telemetry
* Add test for dev mode
This pull request is a temporary addition that uses the `x-now-route-params` header in serverless.
This header returns the regex groups with indexes, not their named variants.
As a result, we must use the getRouteMatcher utility to reverse this into Next.js' expected names.
Since this got complex, I've added a test for it. We should probably remove this behavior sooner than later.
This block seemed redundant
```
To serve static files from the root directory you can add a folder called `public` and reference those files from the root, e.g: `/robots.txt`.
```
The block above this already mentions the same thing:
```
Create a folder called `public` in your project root directory. From your code you can then reference those files starting from the baseURL `/`
```
We could add the `robots.txt` eg to the first block itself if necessary
* Remove static optimization from message
This check does not pertain to automatic static optimization.
Closes https://github.com/zeit/next.js/issues/9042
* Update help message
* Add buildId to SPR data routes
* Update buildId replace in serverless loader
* Use new RegExp and add comment
* Apply suggestions from code review
Co-Authored-By: Joe Haddad <joe.haddad@zeit.co>
* Test to ensure client transition and handle / data route
* Remove experimental.publicDirectory config
* Error when public is set as an output dir
* Remove experimental.publicDirectory checks
* Update publicFiles checking in next build
* Convert Dev Server to TypeScript
This converts the Next.js Development Server to TypeScript in prep for upcoming changes.
* Convert remaining necessary
* Fix some type errors
* Adjust types
* Informative Error for Invalid Global CSS
This adds a helpful error message with a (basic) err.sh link for invalid Global CSS usage.
We'll want to expand on this topic more and offer alternatives when CSS Modules support lands.
* Update expected error message
* Use Better Telemetry Directory
So, as it turns out, storing in `node_modules` is a bad idea.
Both npm and Yarn will remove additional files when you run `npm install` or `yarn install`.
Instead, we'll store this inside of Next.js' `distDir`. This should also be cached by users, if it's not, it probably won't be any worse as compared to `node_modules`.
* Fix directory name
* Fix build setup
* Record when export session is started
* Move more into branch
