- 15 9月, 2020 9 次提交
-
-
由 Joe Haddad 提交于
-
由 JJ Kasper 提交于
On the latest beta of webpack 5 resolving fails with the below error and according to https://github.com/webpack/webpack/issues/11467 is due to the imports in this module not being fully specified. This adds the config mentioned in the thread to correct the resolving for this module. ```sh Failed to compile. -- 16:33:50.046 | ModuleNotFoundError: Module not found: Error: Can't resolve './assertThisInitialized' in '/vercel/f03cc85/node_modules/@babel/runtime/helpers/esm' 16:33:50.046 | > Build error occurred 16:33:50.047 | Error: > Build failed because of webpack errors 16:33:50.047 | at build (/vercel/f03cc85/node_modules/next/dist/build/index.js:15:918) 16:33:50.099 | error Command failed with exit code 1. ```
-
由 Joe Haddad 提交于
-
由 JJ Kasper 提交于
Fixes SSG pages that start with `/api` not being detected as SSG pages. This also adds tests to ensure this is working correctly in the `prerender` suite. x-ref: https://github.com/vercel/next.js/issues/17091
-
由 JJ Kasper 提交于
This continues off of https://github.com/vercel/next.js/pull/17081 and provides this normalized `asPath` value in the context provided to `getServerSideProps` to provide the consistent value since the request URL can vary between direct visit and client transition and the alternative requires building the URL each time manually. Kept this change separate from https://github.com/vercel/next.js/pull/17081 since this is addressing a separate issue and allows discussion separately. Closes: https://github.com/vercel/next.js/issues/16407
-
由 JJ Kasper 提交于
-
由 Joe Haddad 提交于
-
由 JJ Kasper 提交于
-
由 JJ Kasper 提交于
This normalizes the `asPath` for `getServerSideProps` and `getStaticProps` pages to ensure it matches the value that would show on the client instead of a) the output pathname when revalidating or generating a fallback or b) the `_next/data` URL on client transition. Fixes: https://github.com/vercel/next.js/issues/16542
-
- 14 9月, 2020 2 次提交
-
-
由 Jens Meindertsma 提交于
Earlier today #17038 was merged which I opened to fix a problem when using `webpack@5.0.0-beta.30` with Next.js using the new Webpack 5 support. In that PR, the only change was the renaming of a configuration key. I later discovered that the change on the Webpack side was different than I initially thought, and this meant that the fix I submittted to Next.js didn't work. This PR intends to fix the remaining problems. Webpack 5 now accepts a `environment` key that can be used to configure the target output. Previously, this was known as `ecmaVersion` and accepted a number. Now, `environment` accepts a configuration object with individual options. I've configured this in such a way where it resembles an ES5 environment: ```js environment: { arrowFunction: false, bigIntLiteral: false, const: false, destructuring: false, dynamicImport: false, forOf: false, module: false, } ```
-
由 Joe Haddad 提交于
-
- 13 9月, 2020 2 次提交
-
-
由 Bogdan Chadkin 提交于
For some reason babel-plugin-syntax-jsx of babel 6 was used instead of babel 7 version.
-
由 Joe Haddad 提交于
-
- 12 9月, 2020 7 次提交
-
-
由 Tim Neutkens 提交于
-
由 Jens Meindertsma 提交于
This PR fixes #17035. As described in the issue, there was a breaking change in `webpack@5.0.0-beta.30`: `output.ecmaVersion` was replaced by `output.environment`. This meant Next.js apps using this `webpack` version would break. This PR updates the relevant Webpack config. I think this will break any apps that are still using `webpack@5.0.0-beta.29`, but I don't know whether that is a problem as this is a beta feature. If it is, I'd love it if someone could let me know how to detect beta versions in the code so I can make it backwards-compatible.
-
由 Joe Haddad 提交于
-
由 Markus Lautenbach 提交于
Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>
-
由 Ole-Martin Bratteng 提交于
ref https://github.com/GoogleChrome/web-vitals/pull/68 won't fail the new [`no-unload-listeners`](https://github.com/GoogleChrome/lighthouse/pull/11085) Lighthouse audit.
-
由 Joe Haddad 提交于
-
由 Bogdan Chadkin 提交于
Ref https://github.com/webpack-contrib/terser-webpack-plugin/blob/v4.1.0/package.json#L44 cacache is a dependency of terser-webpack-plugin. The latest version depends on cacache 15 while next adds cacache 13. This may give unexpected results. Better keep it in sync with terser plugin.
-
- 11 9月, 2020 7 次提交
-
-
由 Bogdan Chadkin 提交于
Babel-preset-env includes includes optional chaining and nullish-coalescing since [7.8.0](https://github.com/babel/babel/releases/tag/v7.8.0). In this diff I removed these plugins from next preset to prevent dependency duplication when their newer versions are out.
-
由 Bogdan Chadkin 提交于
The new version replaced big clone-deep package with dependency-free klona - https://github.com/webpack-contrib/sass-loader/releases/tag/v10.0.0 - https://github.com/webpack-contrib/sass-loader/releases/tag/v9.0.0 Also deduped some related transitives.
-
由 Sakito Mukai 提交于
There was a security update for node-fetch. > This is an important security release. It is strongly recommended to update as soon as possible. https://github.com/node-fetch/node-fetch/blob/master/docs/CHANGELOG.md#v261
-
由 Joe Haddad 提交于
-
由 JJ Kasper 提交于
This adds an error when interpolation fails to make sure invalid `href`s aren't accidentally used and an invalid URL is built. Closes: https://github.com/vercel/next.js/issues/16944
-
由 Joe Haddad 提交于
-
由 Joe Haddad 提交于
-
- 10 9月, 2020 5 次提交
-
-
-
由 Joe Haddad 提交于
-
由 JJ Kasper 提交于
This makes sure we properly resolve a rewrite when only the `href` value is used. This was causing a full-reload and was missed in the existing test since we weren't making sure a full navigation didn't occur which has been added in this PR. Fixes: https://github.com/vercel/next.js/issues/16974
-
由 Joe Haddad 提交于
-
由 Joe Haddad 提交于
Fixes #10142 Fixes #11629
-
- 09 9月, 2020 3 次提交
-
-
由 Joe Haddad 提交于
-
由 Gerald Monaco 提交于
Removes `next-head-count`, improving support for 3rd party libraries that insert or append new elements to `<head>`. --- This is more or less what a solution with a `data-` attribute would look like, except that instead of directly searching for elements with that attribute, we serialize the elements expected in `<head>` and then find them/assume ownership of them during initialization (in a manner similar to React's reconciliation) based on their properties. There are two main assumptions here: 1. Content is served with compression, so duplicate serialization of e.g. inline script or style tags doesn't have a meaningful impact. Storing a hash would be a potential optimization. 2. 3rd party libraries primarily only insert new, unique elements to head. Libraries trying to actively manage elements that overlap with those that Next.js claims ownership of will still be unsupported. The reason for this roundabout approach is that I'd really like to avoid `data-` if possible, for maximum compatibility. Implicitly adding an attribute could be a breaking change for some class of tools or crawlers and makes it otherwise impossible to insert raw HTML into `<head>`. Adding an unexpected attribute is why the original `class="next-head"` approach was problematic in the first place! That said, while I don't expect this to be more problematic than `next-head-count` (anything that would break in this new model also should have broken in the old model), if that does end up being the case, it might make sense to just bite the bullet. Fixes #11012 Closes #16707 --- cc @Timer @timneutkens
-
由 JJ Kasper 提交于
This makes sure to the page path is the expected version to trigger refreshing on the client and adds additional tests to make sure it is working properly with these page variants. Closes: https://github.com/vercel/next.js/issues/16938
-
- 08 9月, 2020 2 次提交
-
-
由 Tim Neutkens 提交于
-
由 JJ Kasper 提交于
Co-authored-by: NTim Neutkens <timneutkens@me.com>
-
- 07 9月, 2020 3 次提交
-
-
由 Tim Neutkens 提交于
-
由 JJ Kasper 提交于
Co-authored-by: Nkodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
-
由 Tim Neutkens 提交于
-