ESBuild cannot generate package.json with the new TypeScript setup

[rendmath]

Current Behavior

In Nx 19, @nx/esbuild was capable of generating a package.json and package-lock.json with the generatePackageJson option.

In Nx 20, @nx/esbuild returns this error when trying to generate a package.json and package-lock.json with the generatePackageJson option.

 NX   Setting 'generatePackageJson: true' is not supported with the new (default) TypeScript setup. Update the 'package.json' file at the project root as needed and unset the 'generatePackageJson' option.

This feature is a major requirement for building Docker containers, since it allows to only install the NPM packages used by the project and not the NPM packages of the whole workspace.

Am I missing something here?

Expected Behavior

The generatePackageJson options works in @nx/esbuild with the new (default) TypeScript setup (or an alternative option is provided).

GitHub Repo

No response

Steps to Reproduce

For Nx 19

npx create-nx-workspace@19 ws19 --workspaceType=integrated
cd ws19
nx add @nx/node
nx generate @nx/node:application --projectNameAndRootFormat=as-provided --directory=packages/node-esbuild --bundler=esbuild --e2eTestRunner=none --framework=express --unitTestRunner=none
nx build node-esbuild

For Nx 20

npx create-nx-workspace@20 ws20 --ci=skip --formatter=none
cd ws20
nx add @nx/node
nx generate @nx/node:application --directory=packages/node-esbuild --bundler=esbuild --e2eTestRunner=none --framework=express --linter=none --unitTestRunner=none
nx build node-esbuild

Nx Report

Node           : 20.15.1
OS             : win32-x64
Native Target  : x86_64-windows
npm            : 10.8.2

nx                 : 19.8.14
@nx/js             : 19.8.14
@nx/jest           : 19.8.14
@nx/linter         : 19.8.14
@nx/eslint         : 19.8.14
@nx/workspace      : 19.8.14
@nx/devkit         : 19.8.14
@nx/esbuild        : 19.8.14
@nx/eslint-plugin  : 19.8.14
@nx/node           : 19.8.14
@nrwl/tao          : 19.8.14
typescript         : 5.5.4
---------------------------------------
Registered Plugins:
@nx/eslint/plugin

Failure Logs

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[jaytavares]

@FrozenPandaz Is there a status update on this? This is a major issue for anyone who needs to containerize their app (We are using Firebase Cloud functions and have hit a wall on converting our repo to the new, recommended NPM Workspaces/TS Project References approach. Firebase needs a package.json in order to deploy.)

As a workaround, I'm going to try manually including the package.json in the build output as an asset; however, this is definitely not optimal since we're going to have to manually ensure all the necessary dependencies are included.

[jaytavares]

Update with workaround:

I've found a workaround that will be passable for us for now.

I'm maintaining a separate package.json file in a deploy folder. I'm then including that in the build output with the following setting:

"assets": [
            {
              "glob": "package.json",
              "input": "apps/cloud-functions/deploy",
              "output": "."
            }
          ],

I can't simply use the existing package.json because Firebase needs "type": "module",, but if I add that line to the project's package.json, esbuild no longer runs successfully. As noted in my previous comment, this is definitely not a permanent solution as I'm stuck manually maintaining the deployable package.json. If I forget to add a needed dependency, I won't realize it until Continuous Deployment fails. 🤢

[rendmath]

Remark on the workaround suggested by @jaytavares.

In the absence of a package-lock file, the versions of the packages resolved during the installation might be different than the ones that were used for development and/or scanned by our toolchain. Fixing the version of all direct dependencies in the package.json is not sufficient for us because the versions of transitive dependencies could still slide.

So there are some risks of regressions and silent vulnerabilities.

Adding the package-lock of the workspace results in an error of NPM.

[thdk]

Another workaround is to bundle all dependencies together with the source code bundle:

      "options": {
         ...
          "bundle": true,
          "thirdParty": true,
          "generatePackageJson": false,
          "esbuildOptions": {
               ...  
         }
     }

And then remove the install command from the dockerfile.

Does this help any of you?

[motorcityadam]

Another workaround is to bundle all dependencies together with the source code bundle:

      "options": {
         ...
          "bundle": true,
          "thirdParty": true,
          "generatePackageJson": false,
          "esbuildOptions": {
               ...  
         }
     }

And then remove the install command from the dockerfile.

Does this help any of you?

Yes. This is what I forced to do.

It is not a bad strategy for the small Node.js services that I am building to run as Google Run functions. Bigger apps might run into some issues.

BUT for apps targeting Node.js and ESM, I had to add the following ESBuild options. So heads up.

"esbuildOptions": {
  "banner": {
    "js": "const require = await (async () => { const { createRequire } = await import('node:module'); return createRequire(import.meta.url); })();"
  }
}

It has to do with this bug in ESBuild: evanw/esbuild#1921 (comment)

[jaytavares]

Another workaround is to bundle all dependencies together with the source code bundle:

      "options": {
         ...
          "bundle": true,
          "thirdParty": true,
          "generatePackageJson": false,
          "esbuildOptions": {
               ...  
         }
     }

And then remove the install command from the dockerfile.

Does this help any of you?

Unfortunately, no. Firebase requires a package.json in order to emulate/deploy.

[jaysoo]

It's not support due to the output being inside the project root. We are looking at tackling this in a different way where the lockfile does not need @nx/esbuild:esbuild but we can provide a generic way to get a pruned lockfile that's not tied to an executor.

I'll put together an example of this, and we can port some features back into @nx/js.

[astanb]

FWIW I was able to get this working by implementing the PR as mentioned here #29848

[jaysoo]

This is the sample repo: https://github.com/jaysoo/node-acme

Using this Node script to generate lockfile: https://github.com/jaysoo/node-acme/blob/main/tools/lockfile.mjs

We'll make sure it's all done out of the box so users get a sane default setup.