- 15 1月, 2021 3 次提交
-
-
由 Joe Haddad 提交于
-
由 Gerald Monaco 提交于
* Upgrade React version warning * Fix font/stylesheet plugin * Fix size-limit tests * Fix build-output test * Add tests for React 16 * Fix react-dom version
-
由 Guy Bedford 提交于
This picks up on the inlining work in https://github.com/vercel/next.js/pull/20598 to also include webpack loader inlining optimizations. This includes: * The dependencies of sass-loader * resolve-url-loader And for added benefit: * babel-plugin-transform-define * babel-plugin-transform-react-remove-prop-types style-loader and css-loader didn't inline easily. Perhaps we can come back to these ones.
-
- 14 1月, 2021 6 次提交
-
-
由 Joe Haddad 提交于
-
由 Ramiro Silveyra d'Avila 提交于
Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>
-
由 François Billioud 提交于
Rookie mistake
😉 -
由 Guy Bedford 提交于
-
由 kaykdm 提交于
Fixes: https://github.com/vercel/next.js/issues/19100 > According to https://nextjs.org/docs/basic-features/image-optimization#caching Next.js populates a cache dir when using the new <Image /> component. This is not the case when using SVG files. This results in a performance penalty. I created a function for writing images to cache directory (`wrirteToCacheDir`) and it is called for all images. However, vector and animated images are not optimized before writing them to cache dir Related to #18179
-
由 Ari Freyr Asgeirsson 提交于
Hello friends Ran into this bug on our production site, prerenderManifest stores revalidation info for the index as `"/": { .. }`, but the code tries to access this information as `"/index"`. This leads to our index page always having s-max-age: 1
-
- 13 1月, 2021 1 次提交
-
-
由 Janicklas Ralph 提交于
-
- 12 1月, 2021 3 次提交
-
-
由 JJ Kasper 提交于
This helps catch conflicting paths returned from `getStaticPaths` with a friendly error <details> <summary> Preview of error </summary> <img width="962" alt="Screen Shot 2021-01-08 at 5 03 04 PM" src="https://user-images.githubusercontent.com/22380829/104074719-6e481100-51d6-11eb-9397-938aee3ae30b.png"> <img width="962" alt="Screen Shot 2021-01-08 at 5 03 41 PM" src="https://user-images.githubusercontent.com/22380829/104074722-6f793e00-51d6-11eb-90f6-7cdf9882bf00.png"> </details> Closes: https://github.com/vercel/next.js/issues/19527
-
由 Joe Haddad 提交于
-
由 Joe Haddad 提交于
This pull request adds `future.strictPostcssConfiguration`, allowing users to opt-into the more strict PostCSS configuration loading. This stricter PostCSS configuration loading ensures that CSS can be cached across builds.
-
- 11 1月, 2021 6 次提交
-
-
由 Kristoffer K 提交于
**What's the problem this PR addresses?** - ~~https://github.com/vercel/next.js/pull/18768 started to ncc babel and thus it's version of resolve which breaks PnP support~~ Babel replaced `resolve` with the builtin `require.resolve` and a polyfill for older node versions in https://github.com/babel/babel/pull/12439 which was upgraded in https://github.com/vercel/next.js/pull/20586 - `next` unnecessarily bundles the `resolve` package when `require.resolve` is builtin and can do the same job **How did you fix it?** - ~~Avoid running `resolve` through ncc~~ Added a test for https://github.com/vercel/next.js/issues/19334 (closes https://github.com/vercel/next.js/issues/19334) - Replace `resolve` with `require.resolve`
-
由 Kristoffer K 提交于
**What's the problem this PR addresses?** In https://github.com/vercel/next.js/pull/18921 I enabled `absoluteRuntime` for everyone (it was only enabled for PnP users) but didn't consider that people used the babel preset outside of the webpack build. Fixes https://github.com/vercel/next.js/issues/19448 - ~~Since it doesn't contain a repro I can't be certain but based on feedback from @koshea in https://github.com/vercel/next.js/pull/18921#issuecomment-733744645 I'll assume @RossMcMillan92 is doing the same thing, because when next is building it doesn't leave absolute paths as external.~~ Confirmed in https://github.com/vercel/next.js/pull/18921#issuecomment-734224014 **How did you fix it?** Only enable `absoluteRuntime` when the preset is running under `babel-loader`
-
由 Tim Neutkens 提交于
Fixes #20408 Fixes #20925
-
由 Vlad Frolov 提交于
I have not bumped into any bug, I was just playing around https://lgtm.com/projects/g/vercel/next.js/, and this looked like a legit suggestion to fix
-
由 Hyeon Kim (김지현) 提交于
Prevent unpredictable dependency hosting by explicitly resolve module path on webpack.ProvidePlugin (#20971) ProvidePlugin replaces certain identifiers with another modules. As a result, 'buffer' and 'process' modules are added as implicit dependencies to all Next.js plugins. This can be problematic. With "Plug'n'Play" strategy, it don't work at all since they fail-fast with implicit dependencies. With "node_modules" strategy, it might seem OK but actually it can be result into unpredictable behavior since in uses dependency [hoisting](https://yarnpkg.com/advanced/lexicon#hoisting). For example, currently users cannot use next-auth plugin with Plug'n'Play strategy: ![image](https://user-images.githubusercontent.com/4435445/103481517-d5547700-4e1e-11eb-9f23-bc2c9939418e.png) This patch let Next.js properly handles such cases with `require.resolve`. Closes https://github.com/vercel/next.js/issues/20955 ###### References: - https://github.com/nextauthjs/next-auth/pull/1034
-
由 Tim Neutkens 提交于
Fixes #20887
-
- 10 1月, 2021 1 次提交
-
-
由 Tim Neutkens 提交于
-
- 07 1月, 2021 7 次提交
-
-
由 tarunama 提交于
## summary - add return types - move `locale` variable const from let - ~use [strict equality](https://github.com/vercel/next.js/pull/20806/files#diff-2433946f9a058f1b070138d12c20f10a9128e46408033629181f9f7fc3b9b9b2R275)~
-
由 Luc Leray 提交于
Fix all deploy button URLs in the Next.js repo to follow the following format: ``` https://vercel.com/new/git/external?repository-url=https://github.com/vercel/next.js/tree/canary/examples/<EXAMPLE_NAME>&project-name=<EXAMPLE_NAME>&repository-name=<EXAMPLE_NAME> ``` The detailed docs for the Deploy Button can be found here: https://vercel.com/docs/more/deploy-button. Also updates legacy Vercel import flow URLs (starting with vercel.com/import or with vercel.com/new/project), to use the new vercel.com/new URLs. --- For example, for the `hello-world` example: The URL is https://vercel.com/new/git/external?repository-url=https://github.com/vercel/next.js/tree/canary/examples/hello-world&project-name=hello-world&repository-name=hello-world And the deploy button looks like this: [![Deploy with Vercel](https://vercel.com/button)](https://vercel.com/new/git/external?repository-url=https://github.com/vercel/next.js/tree/canary/examples/hello-world&project-name=hello-world&repository-name=hello-world) --- For reference, I used the following regexes to search for the incorrect URLs ``` \(https://vercel.com/import/git\?s=https://github.com/vercel/next.js/tree/canary/examples/(.*)\) \(https://vercel.com/import/git\?c=1&s=https://github.com/vercel/next.js/tree/canary/examples/([^&]*)(.*)\) \(https://vercel.com/import/project\?template=https://github.com/vercel/next.js/tree/canary/examples/(.*)\) https://vercel.com/import/git https://vercel.com/import/select-scope https://vercel.com/import https://vercel.com/new/project ```
-
由 Joe Haddad 提交于
-
由 Joe Haddad 提交于
-
由 David ALLIX 提交于
Follow https://github.com/vercel/next.js/pull/20628
-
由 Joe Haddad 提交于
-
由 Damien Varron 提交于
Fixes #16864 The `router` can be missing in a test environment when trying to render a `Link` component. This PR bails out of `router.prefetch()` when `router` is missing. The alternative is for users to mock `next/link` or to mock the `router` and wrap their test components. Please let me know any feedback.
-
- 06 1月, 2021 5 次提交
-
-
由 JJ Kasper 提交于
This updates the error shown when a path doesn't match the dynamic route in `getStaticPaths` to not include the `locale` since this isn't considered when matching against the dynamic route.
-
由 JJ Kasper 提交于
This ensures rewrites to API routes with i18n enabled handles as an API route correctly. This also adds tests for API routes in the i18n test suite Fixes: https://github.com/vercel/next.js/issues/20725
-
由 Joe Haddad 提交于
-
由 JJ Kasper 提交于
This is a follow-up to https://github.com/vercel/next.js/pull/20596 and https://github.com/vercel/next.js/pull/20658 ensuring the `as` value is prefixed with the `basePath` correctly with a query. This updates the test to also ensure no errors are shown when a query is present on the index `basePath` route. Fixes: https://github.com/vercel/next.js/pull/20757#issuecomment-754338510
-
由 Alex Castle 提交于
This is a #19325 reconfigured to support a loader passed in via a `loader` prop on the Image component, rather than using a config-based approach. The idea is that applications wanting to use a custom loader will create a wrapper element for the image component that incorporates that loader. See a simple example of this pattern in the integration tests. This solution is similar to the one prototyped by @ricokahler in #20213 and described at https://github.com/vercel/next.js/issues/18606#issuecomment-720149156 --- Closes #19325 Fixes #18606
-
- 05 1月, 2021 5 次提交
-
-
由 tarunama 提交于
## summary - Explicitly define return types - Add type of [Observer](https://github.com/vercel/next.js/pull/20728/files#diff-5de64b97b2f26e4e41d197a8295e8750825c75b8ca557a4b947a4c3569345974R7)
-
由 Jan Varho 提交于
Currently pages with `notFound: false` from `getServerSideProps` behave the same as `notFound: true`, i.e. just having the key is enough to result in a 404. This fixes the check in render.tsx and adds tests for it.
-
由 Joe Haddad 提交于
This pull request correctly assigns boolean attributes for `<script />` to match the element as it is created by a server-side render. Prior to this pull request, we'd double-execute `<script>` tags with the `async`, `defer`, or `nomodule` property. --- Fixes #9070
-
由 matamatanot 提交于
As with `const width`, it should be declared just before it is used.
-
由 Kristoffer K 提交于
**What's the problem this PR addresses?** `@next/mdx` adds the webpack loader `@mdx-js/loader` without resolving it to an absolute path Depends on https://github.com/vercel/next.js/pull/17606 **How did you fix it?** `require.resolve` the webpack loader before adding it
-
- 04 1月, 2021 3 次提交
-
-
由 Joe Haddad 提交于
-
由 Kristoffer K 提交于
-
由 Alexander Kachkaev 提交于
This PR is a small follow-up to #14705. It saves Next.js users from falling into a [pretty nasty trap](https://github.com/nodejs/node/issues/36620) in which I ended up last Friday. It took more than two days to investigate what was going on, so I hope I'm the last person who’s doing it
😅 Next.js-specific MWE: https://github.com/kachkaev/hanging-response-in-next-via-redirect-plus-compression (needs to be ran locally using Node 14.0.0+). > <img width="521" alt="Screenshot 2020-12-24 at 20 50 00" src="https://user-images.githubusercontent.com/608862/103105989-a9b8dc00-4629-11eb-9be3-5108755604bf.png"> To reproduce the bug I’m fixing: 1. Pick a large http body size (64 or 128 KB) 1. Check _Call res.end() after res.redirect() in /api/redirect_ 1. Navigate to a heavy page or an api handler via redirect 1. Observe that the http response is never finished. If you set `compress` to `false` in `next.config.js` or pick a small payload size (< `zlib.Z_DEFAULT_CHUNK` after compression), the bug will not be observed. This is explained by the use of `res.on("drain", ...)` [by the `compression` package](https://github.com/expressjs/compression/blob/3fea81d0eaed1eb872bf3e0405f20d9e175ab2cf/index.js#L193-L218). The package itself is not the reason for an issue though, it seems to be in the Node’s built-in `http` package. I’m happy to provide more info or GitHub CI to the MWE if needed. I was also thinking of adding some Next.js-specific testing, but could not come up with a compact and clear test plan. Happy to do this if there are any ideas. cc @botv (author of #14705)
-