rsnext/.vscode/settings.json

82 lines
2.2 KiB
JSON
Raw Normal View History

{
// Formatting using Prettier by default for all languages
"editor.defaultFormatter": "esbenp.prettier-vscode",
// Formatting using Prettier for JavaScript, overrides VSCode default.
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
// Formatting using Rust-Analyzer for Rust.
"[rust]": {
"editor.defaultFormatter": "rust-lang.rust-analyzer"
},
// Linting using ESLint.
"eslint.validate": [
"javascript",
"javascriptreact",
"typescript",
"typescriptreact"
],
// Disable Jest autoRun as otherwise it will start running all tests the first time.
"jest.autoRun": "off",
// Debugging.
"debug.javascript.unmapMissingSources": true,
"files.exclude": {
"*[!test]**/node_modules": true
},
// Ensure enough terminal history is preserved when running tests.
"terminal.integrated.scrollback": 10000,
// Configure todo-tree to exclude node_modules, dist, and compiled.
"todo-tree.filtering.excludeGlobs": [
"**/node_modules",
"**/dist",
"**/compiled"
],
// Match TODO-APP in addition to other TODOs.
"todo-tree.general.tags": [
"BUG",
"HACK",
"FIXME",
"TODO",
"XXX",
"[ ]",
"[x]",
"TODO-APP"
],
// Disable TypeScript surveys.
Enable file nesting for unit test files in vscode (#45329) <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change that you're making: --> Adds support for this type of nesting of files in the VSCode explorer. ![CleanShot 2023-01-27 at 10.52.05@2x.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/VceFdFT9YKEsQBBXXDFJ/74cd9a65-094a-491e-aadd-d65ba63c5b9d/CleanShot%202023-01-27%20at%2010.52.05@2x.png) ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-01-28 14:56:56 +01:00
"typescript.surveys.enabled": false,
// Enable file nesting for unit test files.
"explorer.fileNesting.enabled": true,
"explorer.fileNesting.patterns": {
"*.ts": "$(capture).test.ts, $(capture).test.tsx",
"*.tsx": "$(capture).test.ts, $(capture).test.tsx"
},
// Compile rust-analyzer in a separate directory to avoid conflicts with the main project.
"rust-analyzer.checkOnSave.extraEnv": {
"CARGO_TARGET_DIR": "target/rust-analyzer"
},
"rust-analyzer.server.extraEnv": {
"CARGO_TARGET_DIR": "target/rust-analyzer",
"RUST_BACKTRACE": "0"
},
build(cargo): move workspaces manifest to top level (#48198) <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### How? Closes NEXT- Fixes # --> ### What? This PR changes to the `root` of the cargo workspace to the root of repo itself, allows next-swc and other rust codebase can use repo root as workspace root. ### Why? Currently cargo manifest for the next-swc is not placed under the root of the repo, which makes invocation to the tool requires to change cwd / or set cwd. Similarly needs to open editor to the root of the cargo manifest separately to able to utilize language server kicks in. Moving manifest to the root consolidates those, so can invoke either cli / or editor to the same root of the repo.
2023-04-19 18:38:36 +02:00
"rust-analyzer.cargo.extraEnv": {
"CARGO_TARGET_DIR": "target/rust_analyzer"
},
New app routes resolving logic for turbopack (#47737) ### What? Refactors the resolving logic for the `app` loader tree. This PR ensures it's used to create entrypoints in turbopack. Next up is integrating it into the webpack build too. These changes also ensure that parallel routes resolving is applied, which previously wasn't supported in turbopack. ### Why? Part of the effort to deduplicate critical logic between turbopack/webpack in Next.js, this will help land features in turbopack/webpack at the same time. ### How? Quite a few changes. @sokra helped a ton on this PR. `app_structure.rs` was changed to the new resolving logic so most of the logic is there. Additionally we added support for calling the same function in two ways from Node.js: `turbo.entrypoints.get` and `turbo.entrypoints.getStream`. `get` can be used by `next build` to get the full list of entrypoints/loadertrees once. `getStream` has watching built-in and calls a callback function with the new list anytime a file is added that would change the loadertree. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-04-03 13:07:28 +02:00
"cSpell.words": [
"Entrypoints",
"napi",
"nextjs",
New app routes resolving logic for turbopack (#47737) ### What? Refactors the resolving logic for the `app` loader tree. This PR ensures it's used to create entrypoints in turbopack. Next up is integrating it into the webpack build too. These changes also ensure that parallel routes resolving is applied, which previously wasn't supported in turbopack. ### Why? Part of the effort to deduplicate critical logic between turbopack/webpack in Next.js, this will help land features in turbopack/webpack at the same time. ### How? Quite a few changes. @sokra helped a ton on this PR. `app_structure.rs` was changed to the new resolving logic so most of the logic is there. Additionally we added support for calling the same function in two ways from Node.js: `turbo.entrypoints.get` and `turbo.entrypoints.getStream`. `get` can be used by `next build` to get the full list of entrypoints/loadertrees once. `getStream` has watching built-in and calls a callback function with the new list anytime a file is added that would change the loadertree. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-04-03 13:07:28 +02:00
"opentelemetry",
misc: build output rework (#57440) This PR updates the build output in order to reflect the changes brought by PPR and also to make it more consistent. before ``` ○ (Static) automatically pre-rendered as static HTML ◐ (Partially Pre-Rendered) static parts of the page were pre-rendered and the dynamic parts will be streamed ℇ (Streaming) server-side renders with streaming (uses React 18 SSR streaming or Server Components) λ (Server) server-side renders at runtime (uses getInitialProps or getServerSideProps) ``` after ``` ○ (Static) prerendered as static HTML ◐ (Partial Prerender) prerendered as static HTML with dynamic server-streamed content λ (Dynamic) server-rendered on demand using Node.js ℇ (Edge Runtime) server-rendered on demand using the Edge Runtime ``` <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-10-25 22:19:42 +02:00
"prerendered",
New app routes resolving logic for turbopack (#47737) ### What? Refactors the resolving logic for the `app` loader tree. This PR ensures it's used to create entrypoints in turbopack. Next up is integrating it into the webpack build too. These changes also ensure that parallel routes resolving is applied, which previously wasn't supported in turbopack. ### Why? Part of the effort to deduplicate critical logic between turbopack/webpack in Next.js, this will help land features in turbopack/webpack at the same time. ### How? Quite a few changes. @sokra helped a ton on this PR. `app_structure.rs` was changed to the new resolving logic so most of the logic is there. Additionally we added support for calling the same function in two ways from Node.js: `turbo.entrypoints.get` and `turbo.entrypoints.getStream`. `get` can be used by `next build` to get the full list of entrypoints/loadertrees once. `getStream` has watching built-in and calls a callback function with the new list anytime a file is added that would change the loadertree. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-04-03 13:07:28 +02:00
"Threadsafe",
Add next.config.js options to turbopack warning file (#56207) Went through all options listed in config-shared.ts and added them to the turbopack warning file so that there is a clear list of what is not implemented yet. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-29 14:08:40 +02:00
"Turbopack",
New app routes resolving logic for turbopack (#47737) ### What? Refactors the resolving logic for the `app` loader tree. This PR ensures it's used to create entrypoints in turbopack. Next up is integrating it into the webpack build too. These changes also ensure that parallel routes resolving is applied, which previously wasn't supported in turbopack. ### Why? Part of the effort to deduplicate critical logic between turbopack/webpack in Next.js, this will help land features in turbopack/webpack at the same time. ### How? Quite a few changes. @sokra helped a ton on this PR. `app_structure.rs` was changed to the new resolving logic so most of the logic is there. Additionally we added support for calling the same function in two ways from Node.js: `turbo.entrypoints.get` and `turbo.entrypoints.getStream`. `get` can be used by `next build` to get the full list of entrypoints/loadertrees once. `getStream` has watching built-in and calls a callback function with the new list anytime a file is added that would change the loadertree. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-04-03 13:07:28 +02:00
"zipkin"
],
"grammarly.selectors": [
{
"language": "markdown",
"scheme": "file"
}
],
"typescript.tsdk": "node_modules/typescript/lib"
}