I believe Swagger-js-codegen can help you achieve this.

Just found a project that claims it can generate Nest.js code from a Swagger / OpenAPI spec file:

         swagger-nestjs-codegen on Github and on npmjs.com

Did not test it yet, though.

Martin's answer is most of the way there, but the situation may sometimes require the presence of these Swagger decorators in your models where certain metadata in the OpenAPI spec might not be expressible via inference using just the cli plugin alone.

You can actually use the @ApiXXX decorators in your models, and still import them into your front-end Angular application directly.

To do this, you will use a shim provided by NestJS in the @nestjs/swagger package, along with a little Webpack-fu.

I am also using Nx (16.0.3), Angular (15.2.8), and NestJS (^9.0.0), so I will demonstrate with my own configurations.

• First, in your front-end app's project.json be sure you have your build target configured to use the @nx/angular:webpack-browser executor, and your serve target configured to use the @nx/angular:webpack-dev-server executor. For me, the serve target was the sticking point–I thought I was going crazy when my custom Webpack configuration wasn't being picked up, but it is an absolute requirement that you have both the build and serve targets configured using these executors.
• Be sure your webpack configuration is set up in your front-end's project.json file like so:

{
// ... start of project.json
  "targets": {
    "build": {
      "executor": "@nx/angular:webpack-browser",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/apps/my-angular-app",
        "customWebpackConfig": {
          "path": "apps/my-angular-app/webpack.config.ts"
        }
      }
      // ... remainder of project.json

• Your front-end app's webpack.config.ts should look something like the following:

import path from 'path';

export default function customConfig(config) {
  return {
    ...config,
    resolve: {
      ...config.resolve,
      alias: {
        ...config.resolve.alias,
        // shims out nestjs swagger module in the frontend for DTO sharing
        '@nestjs/swagger': path.resolve(__dirname, '../../node_modules/@nestjs/swagger/dist/extra/swagger-shim')
      }
    }
  };
}

• Import your backend DTO into your front-end service, and enjoy not having to write the same model code twice!

Bonus

Additionally, the Swagger CLI Plugin mentioned by Martin can be used at the same time to take advantage of all of the other benefits it offers.

Assuming you're using the @nx/webpack:webpack executor to build your back-end service and the @nx/js:js executor for serve, you may configure the Swagger CLI Plugin like so:

// ... start of project.json
"targets": {
    "build": {
      "executor": "@nx/webpack:webpack",
      "outputs": ["{options.outputPath}"],
      "defaultConfiguration": "production",
      "options": {
        // ... other options
        "webpackConfig": "apps/my-backend-app/webpack.config.ts",
        "transformers": [
          {
            "name": "@nestjs/swagger/plugin",
            "options": {
              "introspectComments": true
              // other plugin options here
            }
          }
        ]
        // ... other options
      }
      // ... remainder of project.json

To any future reader, please keep in mind that these executor names and options may change from one major version of Nx to another, but the core of the solution is to ensure you configure the @nestjs/swagger shims correctly in your front-end bundler, and that if you so desire, you set up the transformers to use the NestJS Swagger CLI Plugin for your back-end similar to the above.

Tested in Nestjs v9

Suppose the docs path is as follows

http://localhost:3000/docs

Get JSON

http://localhost:3000/docs-json

Get YAML

http://localhost:3000/docs-yaml