* Remove deprecated features
In the next major version we'll want to merge this PR that removes some of the long-time deprecated features, it'll have a positive effect on bundle size.
* Update tests
* Update tests
* Change unsized to layout=fill in test
* Update sizes
* Update rotation test
* Update size limit test
* Update test
* Update test
* Update test
This pull request **temporarily** removes ESLint, as it was not landed in accordance with our standard experimental policies. We are fully committed to landing this change again.
This is being reverted because:
- Next.js has very strict goals for its install size. This feature resulted in adding over 17MB, or a 43.6% increase.
- The feature was not first landed under the `experimental` key in `next.config.js`, rather, it was added under the stable namespace (top-level)
- Using the feature doesn't do a "guided setup" like TypeScript, it should ask you to "bring your own" dependencies for ESLint
- It uses a undesirable ESLint plugin name: `plugin:@next/next/recommended`. This should read out as strictly `next`, or as short as we can get it.
- Does not provide actionable warnings (missing link to resolve issue)
- Does not follow appropriate console output styling. We need to revisit how these are presented.
To re-land this, we need to ensure the following minimums are met:
- Very minor change in install size
- Fully experimental (i.e. flagged) with warnings
- Finalized package name and configuration shape, preferably so we can do ` { extends: 'next' } `.
For #22228
This PR:
- Adds ESLint to toolchain
- Included by default for builds (`next build`)
- Can be enabled for development (`next dev`)
- Custom formatter built for output
- Adds appropriate tests
- Adds two documentation pages
This ensures we exit the build process after the build completes even if timers/connections are left open since this can cause the process to hang indefinitely. This was the previous behavior although got changed un-intentionally in e27b7e996d
This updates our production test with an open timer to ensure it doesn't block the process from completing.
This adds generating a static 500 status page when a `pages/500.js` file is added similar to how we handle generating static 404 pages when `pages/404.js` is present. This allows showing a customized error page when a 500 error occurs in an optimal way.
This corrects this test failing from an arrow function being used in ie11 which isn't supported natively
```
● Production Usage › Dynamic import › default behavior › should not remove css styles for same css file between page transitions
JavascriptError: Error executing JavaScript
at Object.throwDecodedError (../node_modules/selenium-webdriver/lib/error.js:550:15)
at parseHttpResponse (../node_modules/selenium-webdriver/lib/http.js:565:13)
at Executor.execute (../node_modules/selenium-webdriver/lib/http.js:491:26)
```
Serverside Dynamically loaded CSS module file insertion adds css-files as usual static files with special data-n-p tag, that is used in page transition logic. That files get removed on page transition cause they are not explicitly required in scope of page.
Mini-css-extract-plugin adds style tags at chunk insertion without any tags and leave them be, no matter how many page transitions were made.
I removed data-n-p tag from dynamically loaded css module files and added new data-n-d tag for it.
Fixes#16950
Prior to this pull request, Next.js would immediately decode all URLs sent to its server (via `path-match`).
This was rarely needed, and Next.js would typically re-encode the incoming request right away (see all the `encodeURIComponent`s removed in PR diff). This adds unnecessary performance overhead.
Long term, this will also help prevent weird encoding edge-cases like #10004, #10022, #11371, et al.
---
No new tests are necessary for this change because we've extensively tested these edge cases with existing tests.
One test was updated to reflect that we skip decoding in a 404 scenario.
Let's see if all the existing tests pass!
To prevent FOUC, discussed in #10557 i need to store information about css file dependencies for chunk. Right now current implementation just throws away everything but js.
Can there be more than one css file in chunk? If no - code will be simplified.
closes#10557
This fixes a client-side file not being transpiled correctly when rewrites are used. The cross browser tests have been updated to make sure there are rewrites so the related code is included and not dead-code eliminated'
Closes: https://github.com/vercel/next.js/issues/16440
This adds the following Node.js core polyfills only when the import is used:
- `path`
- `stream`
- `vm`
- `crypto`
- `buffer`
Fixes#15948
We'll have a separate issue about adding warnings for the usage of these modules in the browser, some polyfills like crypto are quite heavy and generally not needed for most applications (included accidentally through node_modules).
Initial work to use chunkhashes instead of buildid for the page files in production. This does not change the calculation of the filename itself initially.
Disambiguate between pages/index.js and pages/index/index.js so that they resolve differently.
It all started with a bug in pagesmanifest that propagated throughout the codebase. After fixing pagesmanifest I was able to remove a few hacks here and there and more logic is shared now. especially the logic that resolves an entrypoint back into a route path. To sum up what happened:
- `getRouteFromEntrypoint` is the inverse operation of `getPageFile` that's under `pages/_document.tsx`
- `denormalizePagePath` is the inverse operation of `normalizePagePath`.
Everything is refactored in terms of these operations, that makes their behavior uniform and easier to update/patch in a central place. Before there were subtle differences between those that made `index/index.js` hard to handle.
Some potential follow up on this PR:
- [`hot-reloader`](https://github.com/vercel/next.js/pull/13699/files#diff-6161346d2c5f4b7abc87059d8768c44bR207) still has one place that does very similar behavior to `getRouteFromEntrypoint`. It can probably be rewritten in terms of `getRouteFromEntrypoint`.
- There are a few places where `denormalizePagePath(normalizePagePath(...))` is happening. This is a sign that `normalizePagePath` is doing some validation that is independent of its rewriting logic. That should probably be factored out in its own function. after that I should probably investigate whether `normalizePagePath` is even still needed at all.
- a lot of code is doing `.replace(/\\/g, '')`. If wanted, that could be replaced with `normalizePathSep`.
- It looks to me like some logic that's spread across the project can be centralized in 4 functions
- `getRouteFromEntrypoint` (part of this PR)
- its inverse `getEntrypointFromRoute` (already exists in `_document.tsx` as `getPageFile`)
- `getRouteFromPageFile`
- its inverse `getPageFileFromRoute` (already exists as `findPageFile ` in `server/lib/find-page-file.ts`)
It could be beneficial to structure the code to keep these fuctionalities close together and name them similarly.
- revise `index.amp` handling in pagesmanifest. I left it alone in this PR to keep it scoped, but it may be broken wrt nested index files as well. It might even make sense to reshape the pagesmanifest altogether to handle html/json/amp/... better
* Use core-js promise polyfill for nomodule browsers
Also updated to the core-js@3 features modules instead of importing the exact modules directly.
Fixes#10966
* Simplify reflect and regexp
* Add ie11 test for bad Promise
* Add test script for regexp and ie11
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Fixed pathname check in router
Remove the query portion of the URL when checking paths
* Updated change and added trial test
* Update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
