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.

[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.

[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. :/

[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.

[artursudnik]

to chain the @nx/js:tsc executor to compile specific folders like "migrations", and place them in the final output

this is exactly how I managed to work around this problem