Closes [13709](https://github.com/vercel/next.js/issues/13709).
The solution works, **(tested and confirmed with true and false flags with the latest next version)** though I am quite sure this is not the most elegant and proper way to implement it. I have spent the good part of yesterday and today's morning in order to make it more generic but since it's my first time working with anything related to webpack I have struggled miserably. Last, but not least I'm unsure if this is the most proper naming for the flag.
Please, let me know what you want me to change and I'll get it done asap.
[ch4109]
Closes https://github.com/vercel/next.js/issues/14500
Our current docs for `next/router` use examples from both `useRouter` and `import Router from 'next/router'`, with this PR I'm unifying the API into `useRouter` (`withRouter` is still going to be mentioned multiple times as it is the HOC alternative) and no longer mentioning that you can import a global `Router` object from `next/router`, not sure if I should mention it at least once but that didn't seem to be required.
I also did some structural changes to the docs for `next/router`, now every method starts with a description, then the implementation and explanation of the parameters of the method, and then the usage example, because every method uses the same `Usage` title the hash for them would be something like `#usage`, `#usage-1`, `#usage-2`, e.t.c, so I'm not very happy with this but it looks good.
Feedback wanted 🙏
Noticed while trying to get https://github.com/vercel/next.js/pull/14442 tests to pass. The backslash needs to be double escaped in snapshots. Forward slashes aren't escaped, maybe that was the assumption when this test was written?
* Avoid adding basePath when it's not needed
When using the `basePath` setting, on pages with params it will fire a router change. This will pass the url pathname in the `as` param using the `getUrl()` function. This means the `as` path will be sent through already including the `basePath`, leading to `/basePath/basePath/path` which will cause the router to throw an error.
* lint
* Add test case and ensure removal
* Make sure to re-add before changeState
Co-authored-by: JJ Kasper <jj@jjsweb.site>
I accidentally deleted the repo the original PR was based upon haha.
Anyway, the code was still on my computer so here's a new PR with the same content.
I addressed the latest comments from @lfades in the old PR (https://github.com/vercel/next.js/pull/14180)
I also updated `next-auth` to `2.1.0` and updated the `<Provider />` component in `_app.js` that needed updating since the latest release.
Let me know if I missed anything else, otherwise I think this should be good to go 👍
Warn users and revert their `devtool` when they manually change the `devtool` in development mode. For this addition, I check to ensure the `devtool` is custom (i.e. different than what is set by Next) and has a value (`false` is fine as a custom `devtool`!).
As described in [this issue (13963)](https://github.com/vercel/next.js/issues/13963), changing the `devtool` in development mode can cause issues with performance.
Fixes#13963
Not sure if it's still there for a reason, but from the types for `NoEmitOnErrorsPlugin`
```js
/* @deprecated use config.optimization.noEmitOnErrors */
```
Initial PR to make `next build` work with webpack 5, still needs more work to make sure runtimeChunk and such are shared between pages.
- No longer needs the custom ChunkNamesPlugin as the default behavior was changed
- Dropping AMP First client page bundles is now compatible
This fixes the `basePath` not being used when making requests for the `react-dev-overlay`. We might want to pass down the `basePath` to the overlay instead of relying on the `process.env` injection although may be fine this way, will defer to @Timer for preferred way to pass this value to the dev-overlay
Closes: https://github.com/vercel/next.js/issues/14470
[ch3480]
Fixes https://github.com/vercel/next.js/issues/14242
Closes https://github.com/vercel/next.js/pull/14264
Updated the readme of the `with-zones` example to use `vercel dev` instead, starting the app independently has some routing issues that don't happen on production (due to `vercel.json`), with `vercel dev` the app will match the production deployment on localhost.
Noticed this while reviewing https://github.com/vercel/next.js/pull/14376. After having done https://github.com/vercel/next.js/pull/13699, this code didn't feel right to me:
```js
function prepareRoute(path: string) {
path = delBasePath(path || '')
// this /index rewrite is problematic, it makes pages/index.js
// and pages/index/index.js point to the same thing:
return toRoute(!path || path === '/' ? '/index' : path)
}
```
Added a nested index page to the prerender tests and found it was rendering the `/` route on navigation. This uncovered 2 more places around the dataroute where the index path was not translated correctly.
**edit:**
Just to note that there was nothing wrong with https://github.com/vercel/next.js/pull/14376, the issue was already there, I just noticed it while reading that PR
Noticed while working on https://github.com/vercel/next.js/pull/14400 that the optional catch-all handling was missing in `namedRegex`.
This whole file also seemed quite regex heavy so I took a look at the overall logic and changed a few things. It worked by regex escaping the whole route then unescape the dynamic parts. I changed it to only regex escape the static parts, this eliminates unnecessary back and forth escaping. It also makes the dynamic parts handling more readable. The whole logic is less reliant on regexes and just uses simple string manipulation to translate the route into a regex, I didn't measure anything but as an effect this should make it more performant.
Saw in the client bootstrap script that the error message was printed alongside the stacktrace. This is unnecessary since the stacktrace already includes the error message. In fact, it seems like browsers already do a good job of printing an error with its stacktrace when you just print them using `console.error`. It's a bit minor, but this should shave off a few bytes of the bundle.
We previously used to remove our FOUC helper inside of the style injection to ensure content was shown as fast as possible.
This behavior, however, was problematic for a few reasons:
1. Large JavaScript chunks would take longer than an animation frame to parse, causing FOUC
1. Rendering would sometimes complete before an animation frame, causing improper effects
To fix the latter, we started removing the no FOUC helper **before** rendering, however, we never fixed the former by removing the dead code.
There's not a great way to test this because the FOUC is so fast and flaky, however, this code really shouldn't exist and isn't likely to be re-added (regress).
Also, we already have FOUC tests that occasionally flake, probably due to this.
Fixes#12448Fixes#13058Fixes#11195Fixes#10404
spent a lot of hours trying to figure out why did the editor window not open in the foreground on windows.
The fix was super simple : /
Needed to add `detached: true` option in child_process.spawn call
Fixes: https://github.com/vercel/next.js/issues/14016
As discussed this adds an example to demonstrate how you can achieve proxying upstream requests that didn't match any pages/assets in Next.js which can be helpful in achieving incremental migration
## Summary
This PR adds a basic example of how [Tesfy](https://tesfy.io/) could be integrated with Next.js. Tesfy is a project that I've working on during quarantine weekends, mainly to learn new stuff and provide **free** and **unlimited** A/B Tests and Feature Flags while keeping a good performance and the library [size](https://bundlephobia.com/result?p=react-tesfy@1.2.1) as small as possible.
The configuration file could be set up using a [web application](https://app.tesfy.io/) (hosted in Vercel 🎉 ) or by your self.
## Implementation
- Created `with-tesfy` folder
- Added two pages `index.js` and `features.js` to show how experiments and features could be used
- The only thing that must be persisted is the `userId`. Used a cookie to save it.
- Uses `getServerSideProps` to fetch the configuration file and get/create the `userId`.
## Screenshots
There are some screenshots from the web application. Where you can easily configure experiments and audiences per project. Teams and features will soon be added.
![Screenshot 2020-06-01 at 15 40 49](https://user-images.githubusercontent.com/6877967/83414811-60e7ce80-a41e-11ea-9e5c-887c66e80c65.png)
![Screenshot 2020-06-01 at 15 41 02](https://user-images.githubusercontent.com/6877967/83414823-66451900-a41e-11ea-885b-b58e78b042bb.png)
![Screenshot 2020-06-01 at 15 41 11](https://user-images.githubusercontent.com/6877967/83414828-6a713680-a41e-11ea-90a8-8d39a17f19a1.png)
This is my first PR! sorry if I made something wrong 😞 . Any feedback is more than welcome. Also I want to thank you all for the awesome work with Next.js ❤️
Updates the way filenames are generated for browser compilation.
Notably:
- All entry bundles now have hashes in production, this includes pages (previously pages used a buildId in the path)
- The AmpFiles no longer depends on hardcoded bundle names, it uses the buildManifest instead (internals)
- All cases where we match the page name from the chunk/entrypoint name now use the same function `getRouteFromEntrypoint` (internals)
- In development we no longer include the "faked" `buildId` set to `development` for page files, instead we just use the `/_next/static/pages` path (was `/_next/static/development/pages`). This was changed as it caused unneeded complexity and makes generating the bundles easier (internals)
- Updated tons of tests to be more resilient to these changes by relying on the buildManifest instead of hardcoded paths (internals)
Follow up of these PRs:
https://github.com/vercel/next.js/pull/13759https://github.com/vercel/next.js/pull/13870https://github.com/vercel/next.js/pull/13937https://github.com/vercel/next.js/pull/14130https://github.com/vercel/next.js/pull/14176https://github.com/vercel/next.js/pull/14268Fixes#6303Fixes#12087Fixes#1948Fixes#4368Fixes#4255Fixes#2548
* Remove getInitialProps
* added swr
* Update examples/with-cookie-auth-fauna/pages/profile.js
Co-authored-by: Luis Alvarez D. <luis@vercel.com>
* Update examples/with-cookie-auth-fauna/pages/profile.js
Co-authored-by: Luis Alvarez D. <luis@vercel.com>
* no longer needed
* new .env support
* redirect if not found
* always use latest next version
* no longer needed
* Updated readme
* Updated profile page
* Fixed readme and added deploy button
Co-authored-by: Luis Alvarez D. <luis@vercel.com>
This corrects the `/_next/data` path generated when using `basePath` with `getStaticProps` in a `pages/index.js` file which was previously stripping the `basePath` without checking if `/index` needed to be appended after stripping. This also adds additional checks to the `basePath` test suite to prevent regressing
x-ref: https://github.com/vercel/next.js/pull/9872#issuecomment-646841260