Allow to disable Webpack bundling for NestJS apps

[avchugaev]

Webpack bundles the whole NestJS app into a single file. But the output misses dynamically discovered, imported, and executed files, like database migrations.

Please add an option to disable Webpack and output just compiled .ts files.

More about the webpack: boolean in NestJS CLI config - https://docs.nestjs.com/cli/monorepo#global-compiler-options
As I understand, it does a "compiler" switching based on this flag between webpack and tsc.

UPD 2024-10-03: Consider the approach in reply

[msmikesm]

This is a very good question, also I wanted to use nx for my project but I would like to avoid compiling through webpack.

[kasir-barati]

JFI: Even you simple express app in Nx is using webpack. IDK why though.

[chriscarpenter12]

Just started looking at using nx for a nestjs project, but without separate entity files produced in the dist I don't see how this helps when trying to run migrations for deploying to productions. Seems like a non-starter for my case.

[garshom]

Its the same issue am having with my project, all the.tsfiles are getting bundled into one single main.js file and am missing out on automatically running the migrations , if a flag could be added to disable this

[bloigge]

Also came across this issue. Only solution I found was to directly reference my Entities and Migrations in the DataSource.ts - but this is not ideal...

export default new DataSource({
  type: "postgres",
  host: process.env.POSTGRES_HOST,
  port: parseInt(process.env.POSTGRES_PORT as string),
  username: process.env.POSTGRES_USER,
  password: process.env.POSTGRES_PASSWORD,
  database: process.env.POSTGRES_DB,
  schema: process.env.POSTGRES_SCHEMA,
  ssl: false,
  entities: [
    Project
  ],
  migrations: [
    CreateProjects1678045381543,
    UpdateProjects1678045745944
  ],
  // eslint-disable-next-line @typescript-eslint/ban-ts-comment
  // @ts-ignore TypeORM typings are lacking `cli` entry despite being specified in docs, ref: https://typeorm.io/using-cli#create-a-new-migration
  cli: {
    migrationsDir: join(__dirname, "src/migrations"),
  },
  synchronize: false,
  namingStrategy: new SnakeCaseNamingStrategy(),
});

[Brian-McBride]

Nx has such a strong Angular focus, and I think the core developers are mostly Angular developers.

Considering that Next is quickly becoming (if not has become) the mainly used framework for web development, I'd love to see better overall support and work with Next.
I've been fighting build issues for the last 2 days. I'm getting to the point to checking out something like turborepo. :/

[kasir-barati]

Me too. I mean they are using webpack for the simplest things like ExpressJS.

[alxrodav]

Any update here?

[michaeljauk]

Is there any update?

[risa]

I would also like to see this implemented

[conioX]

Any update guys?

[awuzi]

Is there any update ?

[artursudnik]

+1

[pipeospina1320]

Is there any update?

[dami2]

+1 bump for this, lets keep webpack out of the backend side, please

[kallekulp]

+1 really need this feature!

[thenglong]

+1 really need it

[artursudnik]

+1

[tafaust]

I did build a wicked (feels brittle but I am still kinda proud) solution.

I explicitly added

  "pluginsConfig": {
    "@nx/js": {
      "analyzeSourceFiles": true
    }
  }

to nx.json.
The app build target should look similar to

      "executor": "@nx/js:tsc",
      "outputs": [
        "{options.outputPath}"
      ],
      "defaultConfiguration": "production",
      "options": {
        "generatePackageJson": true,
        "generateLockfile": true,
        "updateBuildableProjectDepsInPackageJson": true,
        "buildableProjectDepsInPackageJsonType": "dependencies",
        ...
      }

which produces .ts/.js files side by side in the dist/apps/your-app/... folder.
Life is not easy though because I heavily use internal buildable (and publishable because just in case) libs... they are not bundled with the app which is kinda a PITA.

How did I solve the struggle with the internal libs? I am using pnpm as a package manager and was able to use its linking. You could either set the link in the version of your libs package.json each but I thought that sucks... so I did an update in my Dockerfile just before running pnpm install --production in my deps stage. This is the jq script I am using to update my scoped packages to the local links.

cat package.json | jq '.dependencies = ( .dependencies | to_entries | map(if .key | startswith("@YOURSCOPE/") then .value = "link:./libnx/\(.key|sub("^@YOURSCOPE/"; ""))" else . end) | from_entries )' | tee package.json

Important... make sure to copy the libs from dist to your docker image as well.

Happy to receive some feedback! :)
Do you guys see any potential for optimization?

[tafaust]

I should add that I had to explicitly add my database driver to the package.json in the app folder because it was omitted from the generated package.json in the dist folder.

[eric-deeporigin]

Any official support to eject webpack from nestjs? Webpack has been causing havoc on our apps

[michaeljauk]

Regarding referencing migration files, there is an rather straightforward workaround.
In TypeORM's case, you just need to add all created migration classes to the migrations array in its config options.

// ... Imports

@Injectable()
export class TypeOrmProvider implements TypeOrmOptionsFactory {
  createTypeOrmOptions(): TypeOrmModuleOptions | Promise<TypeOrmModuleOptions> {
    return {
      type: "postgres",
      host: "foo",
      port: 5432,
      username: "foo",
      password: "foo",
      migrations: [
        InitialChangelog1706807759398,
        RefactorChangelog1707389887104,
        AddColumn1707410043409,
        // Reference all migrations that should run here
      ],
    };
  }
}

It's a bit tedious to do that with every migration, but meh. Better than anything else, I've come around so far.

[MilanKovacic]

I think the best idea (for now) is to update documentation to showcase how to chain the @nx/js:tsc executor to compile specific folders like "migrations", and place them in the final output.

[shivraj-bhagat]

I am also trying to achieve this but the tsconfig.app.json paths are not considered.

[ReptoxX]

How did you manage to get it to work with migrations? I can only add one file in "main" or add every file in "additionalEntryPoints", but i don't want to add every single file to the list.

[artursudnik]

@ReptoxX
first I compile only migrations with the tsc and then specify them as assets so that they are copied to the compiled application code folder

[MilanKovacic]

I am working on adding the example to documentation.

[tafaust]

Just to add to it: The same has to be done for NestJs schedule because those run files which needs to be compiled without bundling.

[ayoubkhial]

Are there any official updates?

[hashirventhodi]

any updates on this?

[rexydye]

+1

[CedricCazin]

Are there any updates?

+1

[JeremiahKoeiman]

Are there any updates?

[MilanKovacic]

You can already replace webpack with swc/tsc using the executors nx provides.

1. Create .swcrc file in the root of the application:

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "decorators": true,
      "dynamicImport": true
    },
    "transform": {
      "legacyDecorator": true,
      "decoratorMetadata": true
    },
    "target": "es2020",
    "externalHelpers": true,
    "keepClassNames": true
  },
  "module": {
    "type": "commonjs"
  },
  "sourceMaps": true,
  "exclude": [
    "jest.config.ts",
    ".*\\.spec.tsx?$",
    ".*\\.test.tsx?$",
    "./src/jest-setup.ts$",
    "./**/jest-setup.ts$",
    ".*.js$"
  ]
}

2. Utilize swc executor in project.json:

{
  "name": "backend",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "apps/backend/src",
  "projectType": "application",
  "targets": {
    "build": {
      "executor": "@nx/js:swc",
      "options": {
        "outputPath": "dist/apps/backend",
        "main": "apps/backend/src/main.ts",
        "tsConfig": "apps/backend/tsconfig.app.json",
        "assets": ["apps/backend/src/assets"]
      }
    },
    "serve": {
      "executor": "@nx/js:node",
      "options": {
        "buildTarget": "backend:build"
      }
    }
  },
  "tags": []
}

Warning

This is just a concept.

[artursudnik]

When trying to use this approach I am getting the following error:

File '[edited]/libs/[edited]/src/index.ts' is not under 'rootDir' '/[edited]/apps/backend'. 'rootDir' is expected to contain all source files
The file is in the program because:
          Imported via '@[edited]/auth0' from file [edited]

Because of this, I gave up trying to use TSC in my project.
Is this something trivial?

[JeremiahKoeiman]

@MilanKovacic The setup I currently use looks like this:

{
  "name": "api",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "apps/api/src",
  "projectType": "application",
  "tags": ["scope:api"],
  "targets": {
    "build": {
      "executor": "@nx/js:swc",
      "defaultConfiguration": "development",
      "options": {
        "outputPath": "dist/apps/api",
        "main": "src/main.ts",
        "tsConfig": "{projectRoot}/tsconfig.app.json",
        "assets": ["src/assets"]
      },
      "configurations": {
        "development": {
          "buildTarget": "api:build:development",
          "swcrc": "{projectRoot}/.dev.swcrc"
        },
        "production": {
          "buildTarget": "api:build:production",
          "swcrc": "{projectRoot}/.prod.swcrc"
        }
      }
    },
    "serve": {
      "executor": "nx:run-commands",
      "options": {
        "command": "nest start",
        "watch": true,
        "config": "{projectRoot}/nest-cli.json",
        "path": "{projectRoot}/tsconfig.app.json",
        "entryFile": "{projectRoot}/src/main.js"
      }
    }
  }
}

Do you think this will also cause problems?

[MilanKovacic]

@artursudnik IIRC that error is caused because TSC (and some other executors) have previously required referenced libraries to be buildable. This should be solvable by passing "external": "all" option to the TSC executor.
Unfortunately, the TSC executor does not have "generatePackageJson" option; workaround is to either copy the full package.json/lock for distribution, or use a programmatic way: https://nx.dev/ci/recipes/other/ci-deployment#programmatic-usage

[MilanKovacic]

@artursudnik I created this example repository. Let me know if it works for you: https://github.com/MilanKovacic/nx-nest-tsc-example

[artursudnik]

@MilanKovacic Thanks a lot! I appreciate it. I'll give this a try as soon as possible :-)

[marc-wilson]

+1

[avchugaev]

I've found a pretty elegant solution to team Webpack with dynamically imported files like migrations.
It's shines in use-cases when you want Webpack to dynamically import files by some pattern.
Webpack comes with a feature require.context which bundles files by pattern and allows you to access those imported modules and do what you need.

In my case I wanted Webpack to dynamically import migration files for TypeORM.
Here's how I achieved this.

Step 1: Install typings for Webpack's require.context:

npm i -D @types/webpack-env

Step 2: Add types inside your app's tsconfig.app.json:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "../../dist/out-tsc",
    "module": "commonjs",
    "types": ["node", "@types/webpack-env"],      // notice "@types/webpack-env" is added in "types" array
    "emitDecoratorMetadata": true,
    "target": "es2021"
  },
  "exclude": ["jest.config.ts", "src/**/*.spec.ts", "src/**/*.test.ts"],
  "include": ["src/**/*.ts"]
}

Step 3: Dynamically import migrations when registering TypeOrmModule in my AppModule:

TypeOrmModule.forRootAsync({
  inject: [ConfigService],
  useFactory: (config: ConfigService<AppEnvironment, true>) => ({
    type: 'postgres',
    host: config.get('PG_HOST'),
    port: config.get('PG_PORT'),
    schema: config.get('PG_SCHEMA'),
    username: config.get('PG_USERNAME'),
    password: config.get('PG_PASSWORD'),
    autoLoadEntities: true,
    migrations: (() => {
      // Create an import context by specifying a relative path to `migrations` folder with a filter by file name ending with `.ts`
      const context = require.context('./migrations', true, /\.ts$/);

      // `context.keys()` returns a list of keys for dynamically imported modules within your bundle.
      // `context(key) returns contents of imported module
      // `context(key).default` returns an `export default` thing of imported module (in my case that's migration class) 
      return context.keys().map((key) => context(key).default);
    })(),
    migrationsRun: true,
    logging: 'all',
  }),
}),

Step 4: Adding migrations

I add migrations manually in migrations folder following file and class naming conventions. But you can try to automate this with your migration tool.

A typical migration file looks like this:

File name:
apps/auth-app/src/app/migrations/1727300953457-create-user-table.ts

File contents:

import { MigrationInterface, QueryRunner, Table } from 'typeorm';

export default class CreateUserTable1727300953457 // <-- notice usage of `export default` because I configured `require.context` to take `default` export
  implements MigrationInterface
{
  async up(runner: QueryRunner) {
    await runner.createTable(
      new Table({
        name: 'user',
        columns: [
          {
            name: 'id',
            type: 'uuid',
            isPrimary: true,
            isGenerated: true,
            generationStrategy: 'uuid',
          },
        ],
      }),
      true
    );
  }

  async down(runner: QueryRunner) {
    await runner.dropTable('user', true);
  }
}

Thats it. Now, when Webpack assembles an application it will find your migrations (or other files) with a hint you provided using require.context.

Afterword

Webpack is a good tool and there's certainly a value in using it.
For example, treeshaking, a faster app load (that's my assumption), a faster transfer of built app files (it takes more time to perform operations on tons of small files like uploading or bulding a docker image).
So let it be :)

[kasir-barati]

So here is my two cent, I did ditch the entire webpack. IDK why Nx is using it so intensely everywhere you can think of. Maybe they have their own reasons but I also have mine to just remove this dep from my backend app.

I am usig ExpressJS and to build my app I used this little trick:

{
  "targets": {
    "build": {
      "executor": "nx:run-commands",
      "options": {
        "parallel": false,
        "commands": [
          {
            "command": "npx tsc --incremental --project ./apps/api/tsconfig.app.json"
          }
        ]
      },
      "outputs": ["{workspaceRoot}/dist/out-tsc/apps/api/src/"]
    },
  }
}

And I do not touch the auto generated serve task.

Here is my repo: https://github.com/kasir-barati/react/blob/45c7e4b9f1e097299a3188d042df5e363eaba728/apps/api/project.json#L8-L19

I have also used this approach in NestJS and it works there too. If this helped you in anyway please consider giving my repo a star.