docs(core): release blog post (#28275)

<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->

## Current Behavior
<!-- This is the behavior we have today -->

## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->

## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->

Fixes #

---------

Co-authored-by: Isaac Mann <[email protected]>
Co-authored-by: Jack Hsu <[email protected]>

Author: 3 people

docs/blog/2024-10-03-nx-20-release.md

@@ -0,0 +1,75 @@
+---
+title: Announcing Nx 20
+slug: announcing-nx-20
+authors: [Mike Hartington]
+tags: [nx, release]
+cover_image: /blog/images/2024-10-03/nx-20-header.png
+---
+
+I know it's hard to believe but Nx 20 is here! There's a lot to cover in this release, so let's just dive right in.
+
+## `@nx` All The Things!
+
+If you've been around the Nx ecosystem for any amount of time, you're probably aware that our plugins were published originally under the `@nrwl` npm scope. Since version 16, we've provided backwards compatibility by reexporting `@nx` scoped packages from `@nrwl`. With Nx 20 though, we'll be officially dropping support for the `@nrwl` scoped packages and they will no longer be published to npm. For projects that still have the older packages in them, our [migration docs][rescope] can guide you to what the new packages are in order for you to update any impacted dependencies.
+
+## TypeScript Project References For Monorepos
+
+[**Project References**](https://www.typescriptlang.org/docs/handbook/project-references.html) allows TypeScript to process individual projects rather than the entire monorepo as whole. This is a huge improvement in terms of build times and developer experience. However, Project References comes with a maintenance cost, as it is up to you to update these references. In a large monorepo, this cost is prohibitive.
+
+With Nx 20, when using `create-nx-workspace --preset=ts`, workspaces will use Project References out of the box. Nx removes the maintenance cost of this feature by automatically updating the references for you when you run `build` or `typecheck` targets. You can also run [`nx sync`](/reference/nx-commands#sync) to update references, and `nx sync:check` in CI to validate the workspace.
+
+In addition to adopting Project References, we're also changing the way we link projects in a TypeScript monorepos. **Workspaces** is the standard way to link packages in monorepos. This is a feature that all modern package managers support, such as [npm](https://docs.npmjs.com/cli/using-npm/workspaces), [yarn](https://yarnpkg.com/features/workspaces), [pnpm](https://pnpm.io/workspaces), and [bun](https://bun.sh/docs/install/workspaces), so taking advantage of it is a no-brainer. Now we have a proper way to provide type information and have your packages available in a way developers are used to.
+
+Note that we've enabled Project References and Workspaces for the TS preset (i.e. `--preset=ts`), and we're working on extending this support for all other presets soon (Angular, React, Vue, Node). If you are an existing Nx user and want to create an empty workspace in the previous "integrated" style, you can use `create-nx-workspace --preset=apps`.
+
+## `@nx/rspack` Graduates From Labs 🎓
+
+[Rspack][rspack] has become one of the most exciting new bundlers in recent years. With a webpack-compatible API, it's a painless migration for folks who want faster builds without having to rewrite their entire build process. At Nx, we're big fans of Rspack and have been working on a plugin for folks who would like to migrate. With that in mind, the `@nx/rspack` plugin has officially been merged into the main Nx repository and will become a fully supported plugin for the ecosystem.
+
+In addition to this, Nx core team member [Colum Ferry][colum] has taken the work he's done on the Rspack plugin and brought it to the Angular ecosystem! He's recently released `@ng-rspack/nx` to bring Rspack support to your Angular projects. Simply install the plugin and generate a new app in your workspace to try it out!
+
+```bash
+# In an Nx Workspace (npx create-nx-workspace)
+# Install Package
+npm install @ng-rspack/nx
+
+# Run the app generator
+npx nx g @ng-rspack/nx: app apps/myapp
+
+# Serve the app
+npx nx serve myapp
+
+# Build the app
+npx nx build myapp
+
+# Run the e2es
+npx nx e2e myapp-e2e
+```
+
+## Nx Release: More Powerful And Flexible Versioning
+
+`nx release` has added many powerful versioning capabilities since it was first made public as part of Nx 19. We are super excited about an in progress ground-up reworking of our versioning logic that powers `nx release` and the programmatic API `releaseVersion()` that will continue to support all these features, and allow for even more complex and large scale workspaces to be supported.
+
+For example, release groups have existed as a concept from the very beginning, but their effectiveness is currently not maximized because it is not supported to have project dependencies that span across release group boundaries. The new version coming in a later Nx v20 minor release makes it possible for any number of dependency relationships to exist across any number of release group boundaries.
+
+Additionally, for workspaces that contain multiple different programming languages, extending the versioning logic within `nx release` can currently be quite verbose, with maintenance being quite a burden due to the business logic that lives within the version generator abstraction, and this is what gets implemented per language/ecosystem.
+
+The Nx Team provides the JavaScript version generator out of the box, so for many users, this is not a concern. But for those working with Go, Rust, Dotnet, Java etc, currently a lot of logic needs to be reimplemented and kept up to date with the latest features. In the upcoming versioning rework, the abstraction required for each new language/ecosystem is tiny and purely deals with interacting with the relevant manifest file and registry, if applicable. All feature capabilities are maintained on the Nx core side. Once this new versioning implementation is available in an Nx v20 minor release we will update our documentation to provide guidance on how to opt in, before it ultimately becomes the primary implementation in Nx v21.
+
+## So Long Derived Directories 👋
+
+Generating apps and libraries in a monorepo is something folks do quite regularly and part of that is telling Nx where it should put things. So you've probably seen this prompt before:
+
+![Derived Path](/blog/images/2024-10-03/derived.png)
+
+This is where the concept of derived directories comes in. It will try to inspect your project and put things where it makes sense. But with Nx 20, we're moving away from using derived directories for generators. Now, you'll need to provide the `directory` where you want your apps or libraries to be generated to.
+
+## Wrapping Up
+
+There's a lot more in Nx 20, so be sure to check the full changelog for all the details on everything in this major release.
+
+- [Nx 20 Changelog](/changelog)
+
+[rspack]: https://rspack.dev
+[rescope]: /deprecated/rescope
+[colum]: https://x.com/FerryColum