docs(core): remove old version warnings (#22704)

Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>

docs/shared/concepts/integrated-vs-package-based.md

@@ -49,7 +49,7 @@ Someone who appreciates the structure and consistency of an integrated repositor
 
 ## Standalone Applications
 
-Nx plugins, especially the [generators](/features/generate-code), [executors](/concepts/executors-and-configurations) and [migrations](/features/automate-updating-dependencies) that come with them, are not only valuable for a monorepo scenario. In fact, many developers use Nx not primarily for its monorepo support, but for its tooling support, particularly its ability to modularize a codebase and, thus, better scale it. In v15.3, Nx introduced support for Standalone Applications. It is like an integrated monorepo setup, but with just a single, root-level application. Think of it as an advanced, more capable Create-React-App or Angular CLI. And obviously, you can still leverage all the generators and executors and structure your application into libraries or submodules.
+Nx plugins, especially the [generators](/features/generate-code), [executors](/concepts/executors-and-configurations) and [migrations](/features/automate-updating-dependencies) that come with them, are not only valuable for a monorepo scenario. In fact, many developers use Nx not primarily for its monorepo support, but for its tooling support, particularly its ability to modularize a codebase and, thus, better scale it. Nx supports standalone applications, which are like an integrated monorepo setup, but with just a single, root-level application. Think of it as an advanced, more capable Create-React-App or Angular CLI. And obviously, you can still leverage all the generators and executors and structure your application into libraries or submodules.
 
 Someone whose main focus is on improving their single application will be most interested in the following features of Nx:
 

docs/shared/daemon.md

@@ -29,9 +29,9 @@ If you ever need to manually shut down the Nx Daemon, you can run `nx reset` wit
 
 ## Turning it Off
 
-As of v13.6.0, the Nx Daemon is enabled by default when running on your local machine. If you want to turn it off
+The Nx Daemon is enabled by default when running on your local machine. If you want to turn it off
 
-- simply set `useDaemonProcess: false` in the runners options in `nx.json` or
+- set `useDaemonProcess: false` in the runners options in `nx.json` or
 - set the `NX_DAEMON` env variable to `false`.
 
 When using Nx in a CI environment, the Nx Daemon is disabled by default. Whether the process runs is determined by the following function: [https://github.com/nrwl/nx/blob/master/packages/nx/src/utils/is-ci.ts](https://github.com/nrwl/nx/blob/master/packages/nx/src/utils/is-ci.ts)

docs/shared/guides/module-federation/micro-frontend-architecture.md

@@ -1,9 +1,7 @@
 # Micro Frontend Architecture
 
-Since version 14, Nx provides
-out-of-the-box [Module Federation](/concepts/module-federation/faster-builds-with-module-federation) support to both
-React
-and Angular. The Micro Frontend (MFE) architecture builds on top of Module Federation by providing _independent
+Nx provides out-of-the-box [Module Federation](/concepts/module-federation/faster-builds-with-module-federation) support to both
+React and Angular. The Micro Frontend (MFE) architecture builds on top of Module Federation by providing _independent
 deployability_.
 
 If you have not read the [Module Federation guide](/concepts/module-federation/faster-builds-with-module-federation)

docs/shared/guides/nx-and-angular-cli.md

@@ -195,9 +195,11 @@ To reiterate: `nx migrate` runs the migrations written by the Angular team the s
 
 The [`nx add` command](/nx-api/nx/documents/add) is similar to the `ng add` command. It installs a given package specifier (e.g. `@nx/react`, `@nx/react@18.1.0`, `@nx/react@latest`) and it runs an `init` or `ng-add` generator if the installed package contains it.
 
-This command was introduced in **Nx 17.3.0**.
+```shell
+nx add [package]
+```
 
-If you're using a version of Nx older than **17.3.0**, we recommend running:
+The command was introduced in **Nx 17.3.0**. If you're using an older version, you can instead run:
 
 {% tabs %}
 {% tab label="npm" %}

docs/shared/guides/setup-incremental-builds-angular.md

@@ -3,10 +3,6 @@
 In this guide we’ll specifically look into which changes need to be made to enable incremental builds for Angular
 applications.
 
-{% callout type="caution" title="Nx > 10.4.0" %}
-Incremental builds requires Nx version 10.4.0 or later.
-{% /callout %}
-
 ## Requirements
 
 If your library consumes any Angular package that has not been compiled with Ivy, you must ensure the

docs/shared/installation/troubleshoot-installation.md

@@ -4,7 +4,7 @@ Here are some common scenarios we came across while trying to run Nx on CIs
 
 ## Native Modules
 
-With more recent versions of Nx, we publish native binaries that should be automatically downloaded and installed when Nx is used.
+Nx publishes native binaries that should be automatically downloaded and installed when Nx is used.
 
 If you see a message saying that your platform is not supported (or that Nx cannot find a `@nx/nx-platform` module for versions of Nx between 15.8 and 16.4), there
 are a few reasons why this could potentially happen:

docs/shared/migration/migration-angular.md

@@ -75,10 +75,6 @@ After the changes are applied, your workspace file structure should look similar
 └── tsconfig.base.json
 ```
 
-### Older Versions of Angular
-
-Support for workspaces with multiple applications and libraries was added in Nx v14.1.0. If you are migrating using an older version of Nx, your workspace can only contain one application and no libraries in order to use the automated migration, otherwise, you can still [migrate manually](/recipes/angular/migration/angular-manual).
-
 ### Modified Folder Structure
 
 The automated migration supports Angular CLI workspaces with a standard structure, configurations and features. If your workspace has deviated from what the Angular CLI generates, you might not be able to use the automated migration and you will need to [manually migrate your workspace](/recipes/angular/migration/angular-manual).

docs/shared/recipes/installation/install-non-javascript.md

@@ -41,9 +41,3 @@ nx graph
 
 {% /tab %}
 {% /tabs %}
-
-{% callout type="note" title="Available since Nx v15.8.7" %}
-
-Support for `--use-dot-nx-installation` was added in Nx v15.8.7. To ensure that it is available, specify the version of nx when running your command so that `npx` doesn't accept an older version that is in the cache. (e.g. `npx nx@latest init`)
-
-{% /callout %}

docs/shared/recipes/running-tasks/root-level-scripts.md

@@ -5,7 +5,7 @@ src="https://www.youtube.com/embed/PRURABLaS8s"
 title="Run root-level NPM scripts with Nx"
 /%}
 
-There are often tasks in a codebase that apply to the whole codebase rather than a single project. Starting with version 15.3.0 of Nx, you can run npm scripts directly from the root `package.json`.
+There are often tasks in a codebase that apply to the whole codebase rather than a single project. Nx can run npm scripts directly from the root `package.json`.
 
 Let's say your root `package.json` looks like this:
 

docs/shared/recipes/running-tasks/workspace-watching.md

@@ -2,10 +2,6 @@
 
 Nx can watch your workspace and execute commands based on project or files changes.
 
-{% callout type="note" title="Nx Versioning" %}
-Workspace watching is available with Nx version 15.4.0 and higher.
-{% /callout %}
-
 Imagine the following project graph with these projects:
 
 {% graph height="450px" %}

docs/shared/recipes/storybook/configuring-storybook.md

@@ -9,7 +9,7 @@ description: This guide explains how Storybook is configured on your Nx workspac
 Read our [Using Storybook in a Nx workspace - Best practices](/nx-api/storybook/documents/best-practices) guide!
 {% /callout %}
 
-Starting with version 15.7, Nx is no longer generating a root Storybook directory and shared root Storybook configurations. Instead, it is only generating a Storybook configuration for each project in your workspace. You may still manually create a root Storybook configuration file, if it is needed for your use case.
+Nx does not generate a root Storybook directory and shared root Storybook configurations. Instead, it only generates a Storybook configuration for each project in your workspace. You may still manually create a root Storybook configuration file, if it is needed for your use case.
 
 You can read all about creating and using a root Storybook configuration in our guide [How to configure Webpack and Vite for Storybook](/recipes/storybook/custom-builder-configs).
 
@@ -26,22 +26,6 @@ All these are automatically generated by Nx, so you don't have to worry about th
 
 If you need to create a root Storybook configuration file, you can do so by creating a `.storybook/main.js|ts` file in your workspace root. Then, you may import this file in your project-level Storybook configuration files. However, this is rarely needed in most cases, since most settings for builders like Webpack and Vite, for example, are already built-in into the Storybook builders.
 
-## Moving away from the root Storybook configuration
-
-If you are using `nx migrate` and you migrate to version 15.7 or later, Nx will try to automatically migrate your root Storybook configuration to the project-level Storybook configuration files. However, if you are not using `nx migrate`, you can still manually migrate your root Storybook configuration to the project-level Storybook configuration files.
-
-If you still want to keep your root Storybook configuration files, and if you have settings there that Nx cannot move to the project-level Storybook configuration files, Nx will leave your files untouched. You may keep your root Storybook configuration files, and Nx will still work as it did.
-
-The Nx migrator will do the following:
-
-1. It will add the `@storybook/addon-essentials` addon to all project-level Storybook configuration files.
-2. It will remove the `@storybook/addon-essentials` addon from the root Storybook configuration file.
-3. If the `addons` array in the root Storybook configuration file is empty after removing the `@storybook/addon-essentials` addon, it will remove the `addons` array from the root Storybook configuration file.
-4. If the `stories` array in the root Storybook configuration file is empty, it will remove the `stories` array from the root Storybook configuration file.
-5. If the root `.storybook/main.js|ts` configuration file is empty after removing the `addons` and `stories` arrays, it will remove the root `.storybook/main.js|ts` Storybook configuration file.
-
-In all the other cases, Nx will not interfere with your Storybook setup.
-
 ## Read our guides for Configuring Storybook
 
 You can read all our guides for configuring Storybook in our [Storybook documents page](/nx-api/storybook/documents).