chore(nx-dev): check for broken anchor links (#23580)
Checks for broken anchor links, except for links that go to `/nx-api` or `/blog` Fixes existing broken anchor links
This commit is contained in:
Isaac Mann
GitHub
parent
6be46cfe56
commit
aedea54624
@ -13,7 +13,7 @@ Nx is a powerful tool that helps you build extensible and maintainable codebases
|
||||
|
||||
In this blog post, we’ll explore how to combine the strengths of Nx and Qwik to create a todo app. To do this, we’ll take advantage of an Nx Plugin that was created by the Qwikifiers team to maximise the integration between Qwik and Nx, called [`qwik-nx`](https://github.com/qwikifiers/qwik-nx).
|
||||
|
||||
> You do not necessarily need to use an Nx Plugin for Qwik. Instead, you could use the [Qwik CLI](https://qwik.dev/docs/getting-started/#create-an-app-using-the-cli) to create your application and [add Nx later](/recipes/adopting-nx/adding-to-existing-project#installing-nx-on-a-non-monorepo-project).
|
||||
> You do not necessarily need to use an Nx Plugin for Qwik. Instead, you could use the [Qwik CLI](https://qwik.dev/docs/getting-started/#create-an-app-using-the-cli) to create your application and [add Nx later](/recipes/adopting-nx/adding-to-existing-project#install-nx-on-a-nonmonorepo-project).
|
||||
> In this blog post we use the `qwik-nx` plugin to leverage better DX provided by the generators offered by the Plugin.
|
||||
|
||||
**Table of Contents**
|
||||
@ -25,11 +25,12 @@ In this blog post, we’ll explore how to combine the strengths of Nx and Qwik t
|
||||
- [Generate a Library](#generate-a-library)
|
||||
- [Add a Qwik Context](#add-a-qwik-context)
|
||||
- [Using the Context](#using-the-context)
|
||||
- [Adding a routeLoader$ to load data on Navigation](#adding-a-to-load-data-on-navigation)
|
||||
- [Adding a `routeLoader$` to load data on Navigation](#adding-a-routeloader-to-load-data-on-navigation)
|
||||
- [Handle the Form Action to add todos](#handle-the-form-action-to-add-todos)
|
||||
- [Improve the Architecture](#improve-the-architecture)
|
||||
- [Conclusion](#conclusion)
|
||||
- [Further Reading](#further-reading)
|
||||
- [Learn more](#learn-more)
|
||||
|
||||
You can learn more about this integration in the video below:
|
||||
|
||||
|
||||
@ -471,7 +471,7 @@ Brandon highlighted a pivotal aspect for OSS package/framework authors: the powe
|
||||
Watch on YouTube:
|
||||
{% youtube src="https://www.youtube.com/watch?v=TTjVcWCdwVY" /%}
|
||||
|
||||
Jon and Max are the masterminds behind [Nx Console](/getting-started/editor-setup#integrate-with-editors), the Nx IDE extension for Code and JetBrains.
|
||||
Jon and Max are the masterminds behind [Nx Console](/getting-started/editor-setup), the Nx IDE extension for Code and JetBrains.
|
||||
|
||||
They mention the release of the JetBrains IDE support earlier this year and give a big shoutout to [Issam](https://github.com/iguissouma) who was the original author of the Nx Console Webstorm community plugin and who helped a lot with the official Nx Console version for JetBrains IDE.
|
||||
|
||||
|
||||
@ -91,7 +91,7 @@ jobs:
|
||||
|
||||
The only reason to modify this file is if you need to change the number of agent machines or there is another type of task that needs to run in CI.
|
||||
|
||||
The `linux-medium-js` name in the CI configuration refers to a built-in launch template that Nx provides. If you can not find a template in [the default list](https://github.com/nrwl/nx-cloud-workflows/blob/main/launch-templates/linux.yaml) that meets your needs, you can provide your own. [With a single yaml file](/ci/features/distribute-task-execution#launch-templates), you can set up your agent environment in exactly the way you want with your own launch template.
|
||||
The `linux-medium-js` name in the CI configuration refers to a built-in launch template that Nx provides. If you can not find a template in [the default list](https://github.com/nrwl/nx-cloud-workflows/blob/main/launch-templates/linux.yaml) that meets your needs, you can provide your own. [With a single yaml file](/ci/reference/launch-templates), you can set up your agent environment in exactly the way you want with your own launch template.
|
||||
|
||||
## Dynamically Allocate Agents
|
||||
|
||||
|
||||
@ -4749,7 +4749,7 @@
|
||||
},
|
||||
{
|
||||
"name": "nx.json reference: inputs and namedInputs",
|
||||
"path": "/reference/nx-json#inputs-&-namedinputs",
|
||||
"path": "/reference/nx-json#inputs-namedinputs",
|
||||
"id": "nxjson-inputs",
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
@ -4757,7 +4757,7 @@
|
||||
},
|
||||
{
|
||||
"name": "Project Configuration reference: inputs and namedInputs",
|
||||
"path": "/reference/project-configuration#inputs-&-namedinputs",
|
||||
"path": "/reference/project-configuration#inputs-and-namedinputs",
|
||||
"id": "project-config-inputs",
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
@ -4808,7 +4808,7 @@
|
||||
},
|
||||
{
|
||||
"name": "nx.json reference: inputs and namedInputs",
|
||||
"path": "/reference/nx-json#inputs-&-namedinputs",
|
||||
"path": "/reference/nx-json#inputs-namedinputs",
|
||||
"id": "nxjson-inputs",
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
@ -4816,7 +4816,7 @@
|
||||
},
|
||||
{
|
||||
"name": "Project Configuration reference: inputs and namedInputs",
|
||||
"path": "/reference/project-configuration#inputs-&-namedinputs",
|
||||
"path": "/reference/project-configuration#inputs-and-namedinputs",
|
||||
"id": "project-config-inputs",
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
|
||||
@ -6508,7 +6508,7 @@
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/reference/nx-json#inputs-&-namedinputs",
|
||||
"path": "/reference/nx-json#inputs-namedinputs",
|
||||
"tags": ["cache-task-results"]
|
||||
},
|
||||
{
|
||||
@ -6519,7 +6519,7 @@
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/reference/project-configuration#inputs-&-namedinputs",
|
||||
"path": "/reference/project-configuration#inputs-and-namedinputs",
|
||||
"tags": ["cache-task-results"]
|
||||
},
|
||||
{
|
||||
@ -6582,7 +6582,7 @@
|
||||
"path": "/reference/nx-json#tasks-runner-options",
|
||||
"tags": ["cache-task-results"]
|
||||
},
|
||||
"/reference/nx-json#inputs-&-namedinputs": {
|
||||
"/reference/nx-json#inputs-namedinputs": {
|
||||
"id": "nxjson-inputs",
|
||||
"name": "nx.json reference: inputs and namedInputs",
|
||||
"description": "",
|
||||
@ -6590,10 +6590,10 @@
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/reference/nx-json#inputs-&-namedinputs",
|
||||
"path": "/reference/nx-json#inputs-namedinputs",
|
||||
"tags": ["cache-task-results"]
|
||||
},
|
||||
"/reference/project-configuration#inputs-&-namedinputs": {
|
||||
"/reference/project-configuration#inputs-and-namedinputs": {
|
||||
"id": "project-config-inputs",
|
||||
"name": "Project Configuration reference: inputs and namedInputs",
|
||||
"description": "",
|
||||
@ -6601,7 +6601,7 @@
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": true,
|
||||
"path": "/reference/project-configuration#inputs-&-namedinputs",
|
||||
"path": "/reference/project-configuration#inputs-and-namedinputs",
|
||||
"tags": ["cache-task-results"]
|
||||
},
|
||||
"/reference/nx-json#generators": {
|
||||
|
||||
@ -226,14 +226,14 @@
|
||||
"file": "",
|
||||
"id": "nxjson-inputs",
|
||||
"name": "nx.json reference: inputs and namedInputs",
|
||||
"path": "/reference/nx-json#inputs-&-namedinputs"
|
||||
"path": "/reference/nx-json#inputs-namedinputs"
|
||||
},
|
||||
{
|
||||
"description": "",
|
||||
"file": "",
|
||||
"id": "project-config-inputs",
|
||||
"name": "Project Configuration reference: inputs and namedInputs",
|
||||
"path": "/reference/project-configuration#inputs-&-namedinputs"
|
||||
"path": "/reference/project-configuration#inputs-and-namedinputs"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
|
||||
@ -15,8 +15,6 @@ Cypress is a test runner built for the modern web. It has a lot of great feature
|
||||
## Setting Up @nx/cypress
|
||||
|
||||
> Info about [Cypress Component Testing can be found here](/recipes/cypress/cypress-component-testing)
|
||||
>
|
||||
> Info about [using Cypress and Storybook can be found here](/recipes/storybook/overview-react#cypress-tests-for-storiesbook)
|
||||
|
||||
### Installation
|
||||
|
||||
@ -238,7 +236,7 @@ For adding more dynamic configurations to your Cypress configuration, you can lo
|
||||
|
||||
If you need to pass a variable to Cypress that you don't want to commit to your repository (i.e. API keys, dynamic values based on configurations, API URLs), you can use [Cypress environment variables](https://docs.cypress.io/guides/guides/environment-variables).
|
||||
|
||||
There are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the `-e` Cypress arg or the `env` option from the `@nx/cypress:cypress` executor in the [project configuration](/reference/project-configuration#targets) or the command line.
|
||||
There are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the `-e` Cypress arg or the `env` option from the `@nx/cypress:cypress` executor in the [project configuration](/reference/project-configuration#task-definitions-targets) or the command line.
|
||||
|
||||
Create a `cypress.env.json` file in the projects root (i.e. `apps/my-cool-app-e2e/cypress.env.json`). Cypress will automatically pick up this file. This method is helpful for configurations that you don't want to commit. Just don't forget to add the file to the `.gitignore` and add documentation so people in your repo know what values to populate in their local copy of the `cypress.env.json` file.
|
||||
|
||||
|
||||
@ -119,7 +119,7 @@ Since each Storybook, in this case, is attached to a project, so is the serving
|
||||
|
||||
#### Publishing
|
||||
|
||||
When you are publishing your Storybook, you can follow the same principles described in the [Applications and Libraries Mental Model](/concepts/decisions/project-size#mental-model) documentation page. The general idea is to have one central Storybook container, into which you are going to gather your stories from multiple libraries.
|
||||
When you are publishing your Storybook, you can follow the principles described in the [project size](/concepts/decisions/project-size) decision page. The general idea is to have one central Storybook container, into which you are going to gather your stories from multiple libraries.
|
||||
|
||||
You can think of the central Storybook container as a grouping of similar-concept or same-scope UI parts of your workspace. In the same way you are scoping libraries, you can group your stories as well.
|
||||
|
||||
|
||||
@ -1391,7 +1391,7 @@
|
||||
"id": "nxjson-inputs",
|
||||
"file": "",
|
||||
"tags": ["cache-task-results"],
|
||||
"path": "/reference/nx-json#inputs-&-namedinputs",
|
||||
"path": "/reference/nx-json#inputs-namedinputs",
|
||||
"isExternal": true
|
||||
},
|
||||
{
|
||||
@ -1399,7 +1399,7 @@
|
||||
"id": "project-config-inputs",
|
||||
"file": "",
|
||||
"tags": ["cache-task-results"],
|
||||
"path": "/reference/project-configuration#inputs-&-namedinputs",
|
||||
"path": "/reference/project-configuration#inputs-and-namedinputs",
|
||||
"isExternal": true
|
||||
},
|
||||
{
|
||||
|
||||
@ -155,7 +155,7 @@ secret:
|
||||
We send out emails with every new Nx Cloud release to all our Enterprise customers:
|
||||
|
||||
1. You can view your current version at the `/version` route: https://your-nx-cloud-url.com/version
|
||||
2. [And these are the latest Nx Cloud releases](/ci/reference/release-notes#docker-containers)
|
||||
2. [And these are the latest Nx Cloud releases](/ci/reference/release-notes)
|
||||
|
||||
To upgrade to a newer version, add the below line to your `myconfiguration.yml` file:
|
||||
|
||||
|
||||
@ -326,7 +326,7 @@ nx-cloud validate --workflow-file=./.nx/workflows/agents.yaml
|
||||
|
||||
## Pass Environment Variables to Agents
|
||||
|
||||
If you need to send environment variables to agents, you can use the [--with-env-vars](/ci/reference/nx-cloud-cli#withenvvars) flag on the `nx-cloud start-ci-run` command. You can pass a specific list of environment variables like this:
|
||||
If you need to send environment variables to agents, you can use the [--with-env-vars](/ci/reference/nx-cloud-cli#withenvvars-nx-agents-only) flag on the `nx-cloud start-ci-run` command. You can pass a specific list of environment variables like this:
|
||||
|
||||
```
|
||||
nx-cloud start-ci-run --distribute-on="8 linux-medium-js" --with-env-vars="VAR1,VAR2"
|
||||
|
||||
@ -148,7 +148,7 @@ To enable the light runner feature, make sure you:
|
||||
|
||||
##### Nx Agents
|
||||
|
||||
This release is also the first one to support ["Nx Agents"](/ci/features/distribute-task-execution#managed-agents-seamless-configuration).
|
||||
This release is also the first one to support ["Nx Agents"](/ci/features/distribute-task-execution).
|
||||
|
||||
While currently experimental and disabled by default for on-prem users, we are looking for more on-prem workspaces to try it out with
|
||||
so please reach out to your DPE contact or to [cloud-suppport@nrwl.io](mailto:cloud-support@nrwl.io) if you are interested in helping us shape this according to your needs!
|
||||
|
||||
@ -149,7 +149,7 @@ By default, the computation hash for say `nx test app1` includes:
|
||||
- All the source files of `app1` and `lib`
|
||||
- Relevant global configuration
|
||||
- Versions of external dependencies
|
||||
- [Runtime values provisioned by the user](/concepts/how-caching-works#runtime-hash-inputs)
|
||||
- [Runtime values provisioned by the user](/reference/inputs#runtime-inputs)
|
||||
- CLI Command flags
|
||||
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ The `runtimeCacheInputs` property was used as a way to add extra inputs to the N
|
||||
}
|
||||
```
|
||||
|
||||
Instead of specifying the runtime inputs in `tasksRunnerOptions`, in Nx 14.4 you can include them as runtime inputs in the standard [`inputs` and `namedInputs` area of your project configuration](/reference/project-configuration#inputs-&-namedinputs) or [`nx.json`](/reference/nx-json#inputs-&-namedinputs).
|
||||
Instead of specifying the runtime inputs in `tasksRunnerOptions`, in Nx 14.4 you can include them as runtime inputs in the standard [`inputs` and `namedInputs` area of your project configuration](/reference/project-configuration#inputs-and-named-inputs) or [`nx.json`](/reference/nx-json#inputs-namedinputs).
|
||||
|
||||
The new style looks like this:
|
||||
|
||||
|
||||
@ -100,23 +100,23 @@ Creating the equivalent configuration with Nx yields the following files:
|
||||
|
||||
For each `turbo.json` configuration property, the equivalent Nx property is listed.
|
||||
|
||||
| **Global Configuration:** | |
|
||||
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `globalDependencies` | add to the [`sharedGlobals` `namedInput`](/recipes/running-tasks/configure-inputs) |
|
||||
| `globalEnv` | add to the [`sharedGlobals` `namedInput`](/recipes/running-tasks/configure-inputs) as an [`env` input](/reference/project-configuration#env-variables) |
|
||||
| `globalPassThroughEnv` | N/A. See [Defining Environment Variables](/recipes/tips-n-tricks/define-environment-variables) |
|
||||
| `globalDotEnv` | add to the [`sharedGlobals` `namedInput`](/recipes/running-tasks/configure-inputs) |
|
||||
| **Global Configuration:** | |
|
||||
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `globalDependencies` | add to the [`sharedGlobals` `namedInput`](/recipes/running-tasks/configure-inputs) |
|
||||
| `globalEnv` | add to the [`sharedGlobals` `namedInput`](/recipes/running-tasks/configure-inputs) as an [`env` input](/reference/inputs#environment-variables) |
|
||||
| `globalPassThroughEnv` | N/A. See [Defining Environment Variables](/recipes/tips-n-tricks/define-environment-variables) |
|
||||
| `globalDotEnv` | add to the [`sharedGlobals` `namedInput`](/recipes/running-tasks/configure-inputs) |
|
||||
|
||||
| **Task Configuration:** | |
|
||||
| ------------------------------- | ---------------------------------------------------------------------------------------------- |
|
||||
| `extends` | N/A. The project configurations will always extend the `targetDefaults` defined in `nx.json`. |
|
||||
| `pipeline[task].dependsOn` | [Same syntax](/reference/project-configuration#dependson). |
|
||||
| `pipeline[task].dotEnv` | Define [file `inputs`](/reference/project-configuration#filesets) |
|
||||
| `pipeline[task].env` | Define [env `inputs`](/reference/project-configuration#env-variables) |
|
||||
| `pipeline[task].dotEnv` | Define [file `inputs`](/reference/inputs#source-files) |
|
||||
| `pipeline[task].env` | Define [env `inputs`](/reference/inputs#environment-variables) |
|
||||
| `pipeline[task].passThroughEnv` | N/A. See [Defining Environment Variables](/recipes/tips-n-tricks/define-environment-variables) |
|
||||
| `pipeline[task].outputs` | [Same syntax](/reference/project-configuration#outputs). |
|
||||
| `pipeline[task].cache` | [Same syntax](/reference/project-configuration#cache) |
|
||||
| `pipeline[task].inputs` | [Same syntax](/reference/project-configuration#filesets). |
|
||||
| `pipeline[task].inputs` | [Same syntax](/reference/inputs#source-files). |
|
||||
| `pipeline[task].outputMode` | Use the [`--output-style` command line flag](/nx-api/nx/documents/run-many#output-style) |
|
||||
| `pipeline[task].persistent` | N/A. |
|
||||
|
||||
@ -125,7 +125,7 @@ For each `turbo.json` configuration property, the equivalent Nx property is list
|
||||
| | |
|
||||
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `turbo run test lint build` | [`nx run-many -t test lint build`](/nx-api/nx/documents/run-many) |
|
||||
| `--cache-dir` | Set in [`nx.json` under `cacheDirectory`](/reference/nx-json#cache-directory) |
|
||||
| `--cache-dir` | Set in [`nx.json` under `cacheDirectory`](/reference/nx-json#task-options) |
|
||||
| `--concurrency` | [`--parallel`](/nx-api/nx/documents/run-many#parallel) |
|
||||
| `--continue` | [Use `--nx-bail`](/nx-api/nx/documents/run-many#nx-bail) with the inverse value |
|
||||
| `--cwd` | Available when using the [`run-commands` executor](/nx-api/nx/executors/run-commands#cwd) |
|
||||
@ -143,7 +143,7 @@ For each `turbo.json` configuration property, the equivalent Nx property is list
|
||||
| `--output-logs` | Use [`--output-style`](/nx-api/nx/documents/run-many#output-style) |
|
||||
| `--only` | N/A |
|
||||
| `--parallel` | N/A |
|
||||
| `--remote-only` | N/A. Can [ignore the remote cache](/ci/features/remote-cache#skipping-cloud) with `--no-cloud`. |
|
||||
| `--remote-only` | N/A. Can [ignore the remote cache](/ci/features/remote-cache#skipping-cloud-cache) with `--no-cloud`. |
|
||||
| `--summarize` | N/A |
|
||||
| `--token` | Set the [Nx Cloud token in `nx.json`](/ci/recipes/security/access-tokens#setting-access-tokens) or as an environment variable (`NX_CLOUD_ACCESS_TOKEN`) |
|
||||
| `--team` | See `--token` for choosing a different Nx Cloud workspace. You can [use `--runner`](/nx-api/nx/documents/run-many#runner) to choose a different runner defined in the `nx.json` file. |
|
||||
|
||||
@ -15,8 +15,6 @@ Cypress is a test runner built for the modern web. It has a lot of great feature
|
||||
## Setting Up @nx/cypress
|
||||
|
||||
> Info about [Cypress Component Testing can be found here](/recipes/cypress/cypress-component-testing)
|
||||
>
|
||||
> Info about [using Cypress and Storybook can be found here](/recipes/storybook/overview-react#cypress-tests-for-storiesbook)
|
||||
|
||||
### Installation
|
||||
|
||||
@ -238,7 +236,7 @@ For adding more dynamic configurations to your Cypress configuration, you can lo
|
||||
|
||||
If you need to pass a variable to Cypress that you don't want to commit to your repository (i.e. API keys, dynamic values based on configurations, API URLs), you can use [Cypress environment variables](https://docs.cypress.io/guides/guides/environment-variables).
|
||||
|
||||
There are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the `-e` Cypress arg or the `env` option from the `@nx/cypress:cypress` executor in the [project configuration](/reference/project-configuration#targets) or the command line.
|
||||
There are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the `-e` Cypress arg or the `env` option from the `@nx/cypress:cypress` executor in the [project configuration](/reference/project-configuration#task-definitions-targets) or the command line.
|
||||
|
||||
Create a `cypress.env.json` file in the projects root (i.e. `apps/my-cool-app-e2e/cypress.env.json`). Cypress will automatically pick up this file. This method is helpful for configurations that you don't want to commit. Just don't forget to add the file to the `.gitignore` and add documentation so people in your repo know what values to populate in their local copy of the `cypress.env.json` file.
|
||||
|
||||
|
||||
@ -119,7 +119,7 @@ Since each Storybook, in this case, is attached to a project, so is the serving
|
||||
|
||||
#### Publishing
|
||||
|
||||
When you are publishing your Storybook, you can follow the same principles described in the [Applications and Libraries Mental Model](/concepts/decisions/project-size#mental-model) documentation page. The general idea is to have one central Storybook container, into which you are going to gather your stories from multiple libraries.
|
||||
When you are publishing your Storybook, you can follow the principles described in the [project size](/concepts/decisions/project-size) decision page. The general idea is to have one central Storybook container, into which you are going to gather your stories from multiple libraries.
|
||||
|
||||
You can think of the central Storybook container as a grouping of similar-concept or same-scope UI parts of your workspace. In the same way you are scoping libraries, you can group your stories as well.
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ npm create astro@latest
|
||||
|
||||
## Add Nx
|
||||
|
||||
We can leverage [`nx init`](/recipes/adopting-nx/adding-to-existing-project#installing-nx-on-a-non-monorepo-project) to add Nx to the Astro application.
|
||||
We can leverage [`nx init`](/recipes/adopting-nx/adding-to-existing-project#install-nx-on-a-nonmonorepo-project) to add Nx to the Astro application.
|
||||
|
||||
```{% command="npx nx@latest init" path="~/astro-app"%}
|
||||
NX 🐳 Nx initialization
|
||||
|
||||
@ -17,7 +17,7 @@ Problem: A task is being executed when you expect it to be replayed from the cac
|
||||
- To check your input glob patterns file-by-file, you can get a list of all the files associated with each project by running `nx graph --file=output.json` or by clicking on a task in the task graph in the `nx graph` visualization.
|
||||
|
||||
1. Use the Nx Cloud troubleshooting tools
|
||||
- Make sure your repo is [connected to Nx Cloud](/features/cache-task-results#remote-computation-caching)
|
||||
- Make sure your repo is [connected to Nx Cloud](/ci/features/remote-cache)
|
||||
- Click on the run details link that is printed in the terminal after you run a task
|
||||
- Expand a task that had a cache miss
|
||||
- Click "Check For Near Misses" to see other similar tasks
|
||||
|
||||
@ -240,7 +240,7 @@ nx test myreactapp
|
||||
```
|
||||
|
||||
{% cards %}
|
||||
{% card title="nx.json reference" type="documentation" description="namedInputs can be defined in nx.json" url="/reference/nx-json#inputs-&-namedinputs" /%}
|
||||
{% card title="Project configuration reference" type="documentation" description="inputs and namedInputs can be defined in project configuration" url="/reference/nx-json#inputs-&-namedinputs" /%}
|
||||
{% card title="nx.json reference" type="documentation" description="namedInputs can be defined in nx.json" url="/reference/nx-json#inputs-namedinputs" /%}
|
||||
{% card title="Project configuration reference" type="documentation" description="inputs and namedInputs can be defined in project configuration" url="/reference/project-configuration#inputs-and-named-inputs" /%}
|
||||
{% card title="Configure Inputs for Task Caching" type="documentation" description="This recipes walks you through a few examples of how to configure inputs and namedInputs" url="/recipes/running-tasks/configure-inputs" /%}
|
||||
{% /cards %}
|
||||
|
||||
@ -506,7 +506,7 @@ export class AppComponent {
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1416" /%} -->
|
||||
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
|
||||
Just run:
|
||||
|
||||
|
||||
@ -799,7 +799,7 @@ A couple of notes:
|
||||
|
||||
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=958" /%}
|
||||
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
|
||||
Just run:
|
||||
|
||||
|
||||
@ -585,7 +585,7 @@ export default App;
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1416" /%} -->
|
||||
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
|
||||
Just run:
|
||||
|
||||
|
||||
@ -612,7 +612,7 @@ export default App;
|
||||
|
||||
## Visualizing your Project Structure
|
||||
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
|
||||
Just run:
|
||||
|
||||
|
||||
@ -627,7 +627,7 @@ Note that both the `Products` component and `Orders` component are lazy loaded s
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZAO0yXupIIE?t=958" /%} -->
|
||||
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) and more. Interestingly you can also visualize it.
|
||||
|
||||
Just run:
|
||||
|
||||
|
||||
@ -234,7 +234,7 @@ Typically, you want to set the base SHA not the most recent commit on the `main`
|
||||
- [Get last successful commit for Azure Pipelines](/ci/recipes/set-up/monorepo-ci-azure#get-the-commit-of-the-last-successful-build)
|
||||
- [Get last successful commit for GitHub Actions](/ci/recipes/set-up/monorepo-ci-github-actions#get-the-commit-of-the-last-successful-build)
|
||||
- [Get last successful commit for CircleCI](/ci/recipes/set-up/monorepo-ci-circle-ci#get-the-commit-of-the-last-successful-build)
|
||||
- [Get last successful commit for GitLab](/ci/recipes/set-up/monorepo-ci-gitlab#process-only-affected-projects-with-one-job-on-gitlab)
|
||||
- [Get last successful commit for GitLab](/ci/recipes/set-up/monorepo-ci-gitlab)
|
||||
- [Get last successful commit for Jenkins](/ci/recipes/set-up/monorepo-ci-jenkins#get-the-commit-of-the-last-successful-build)
|
||||
|
||||
## Ignoring Files from Affected Commands
|
||||
|
||||
@ -43,8 +43,8 @@ function extractAllLinks(basePath: string): Record<string, string[]> {
|
||||
.concat(cardLinks)
|
||||
.filter(isLinkInternal)
|
||||
.filter(isNotAsset)
|
||||
.filter(isNotImage)
|
||||
.map(removeAnchors);
|
||||
.filter(isNotImage);
|
||||
// .map(removeAnchors);
|
||||
if (links.length) {
|
||||
acc[path.replace(basePath, '')] = links;
|
||||
}
|
||||
@ -96,25 +96,88 @@ function readSiteMapLinks(filePath: string): string[] {
|
||||
|
||||
// Main
|
||||
const documentLinks = extractAllLinks(join(workspaceRoot, 'docs'));
|
||||
const sitemapLinks = readSiteMapIndex(
|
||||
const sitemapUrls = readSiteMapIndex(
|
||||
join(workspaceRoot, 'dist/nx-dev/nx-dev/public/'),
|
||||
'sitemap.xml'
|
||||
).flatMap((path) => readSiteMapLinks(path));
|
||||
function headerToAnchor(line: string): string {
|
||||
return line
|
||||
.replace(/[#]+ /, '')
|
||||
.replace(/`.*`/, '')
|
||||
.replace(/[^\w ]/g, '')
|
||||
.trim()
|
||||
.replace(/ +/g, '-')
|
||||
.toLocaleLowerCase();
|
||||
}
|
||||
|
||||
function readApiJson(manifestFileName: string): string[] {
|
||||
const manifest = JSON.parse(
|
||||
readFileContents(
|
||||
join(
|
||||
workspaceRoot,
|
||||
'dist/nx-dev/nx-dev/public/documentation/generated/manifests',
|
||||
manifestFileName
|
||||
)
|
||||
)
|
||||
);
|
||||
let entries = Object.entries(manifest);
|
||||
return entries
|
||||
.filter(
|
||||
([url, details]: [string, any]) =>
|
||||
!!details.file &&
|
||||
existsSync(join(workspaceRoot, 'docs', details.file + '.md'))
|
||||
)
|
||||
.flatMap(([url, details]: [string, any]) => {
|
||||
const headers = readFileContents(
|
||||
join(workspaceRoot, 'docs', details.file + '.md')
|
||||
)
|
||||
.split('\n')
|
||||
.filter((line) => line.startsWith('#'))
|
||||
.map(headerToAnchor)
|
||||
.map((line) => url + '#' + line);
|
||||
return headers;
|
||||
});
|
||||
}
|
||||
|
||||
const anchorUrls = ['nx.json', 'ci.json', 'extending-nx.json'].flatMap(
|
||||
(manifestFileName) => readApiJson(manifestFileName)
|
||||
);
|
||||
const ignoreAnchorUrls = ['/nx-api', '/blog'];
|
||||
|
||||
const errors: Array<{ file: string; link: string }> = [];
|
||||
const localLinkErrors: Array<{ file: string; link: string }> = [];
|
||||
for (let file in documentLinks) {
|
||||
for (let link of documentLinks[file]) {
|
||||
if (link.startsWith('https://nx.dev')) {
|
||||
localLinkErrors.push({ file, link });
|
||||
} else if (!sitemapLinks.includes(['https://nx.dev', link].join(''))) {
|
||||
} else if (
|
||||
link.includes('#') &&
|
||||
!ignoreAnchorUrls.some((ignoreAnchorUrl) =>
|
||||
link.startsWith(ignoreAnchorUrl)
|
||||
) &&
|
||||
!anchorUrls.includes(link)
|
||||
) {
|
||||
errors.push({ file, link });
|
||||
} else if (
|
||||
!link.includes('#') &&
|
||||
!sitemapUrls.includes(['https://nx.dev', link].join(''))
|
||||
) {
|
||||
errors.push({ file, link });
|
||||
} else if (
|
||||
link.includes('#') &&
|
||||
ignoreAnchorUrls.some((ignoreAnchorUrl) =>
|
||||
link.startsWith(ignoreAnchorUrl)
|
||||
) &&
|
||||
!sitemapUrls.includes(['https://nx.dev', removeAnchors(link)].join(''))
|
||||
) {
|
||||
errors.push({ file, link });
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
const imageLinks = extractImageLinks(join(workspaceRoot, 'docs'));
|
||||
for (let file in imageLinks) {
|
||||
for (let link of imageLinks[file]) {
|
||||
const imageUrls = extractImageLinks(join(workspaceRoot, 'docs'));
|
||||
for (let file in imageUrls) {
|
||||
for (let link of imageUrls[file]) {
|
||||
if (!existsSync(join(workspaceRoot, 'docs', link))) {
|
||||
errors.push({ file, link });
|
||||
}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user