Forge app fails to build when nx workspace also uses v19 of @nx/nest plugin

[zjkipping]

Having this issue while upgrading our monorepo to nx v19 (and all it's plugins as well).

We are making use of v5.x.x of this nx-forge plugin as well as v19.x.x of @nx/nest (well at least trying to). For some reason the build of the forge app throws the below error... This doesn't happen when using a nest app generated/versioned on @nx/nest v17.x.x. The error also happens with v18.x.x of @nx/nest as well, but we are trying to go 19 so that doesn't matter as much. Currently we just didn't upgrade the nest version to avoid this error, but was wondering if there is any insight that can be gleamed? I think the nest app does a webpack build so possibly those versions are messing up the forge app build?

Github reproduction here: https://github.com/zjkipping/forge-nest-nx-plugins-issue

$ npx nx build forge-app --verbose

> nx run forge-app:build

 NX   Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
    at getOptions (node:internal/fs/utils:325:20)
    at Object.readFileSync (node:fs:447:13)
    at readFileSync (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:85:19)
    at loadTsconfig (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:90:24)
    at loadTsconfigFromExtends (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:134:18)
    at loadTsconfig (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:108:20)
    at loadTsconfigFromExtends (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:134:18)
    at loadTsconfig (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:108:20)
    at loadTsconfigFromExtends (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:134:18)
    at loadTsconfig (C:\Users\zjkip\Documents\code\web\forge-nest-nx-plugins-issue\node_modules\tsconfig-paths\lib\tsconfig-loader.js:108:20)

Any help at all would be appreciated, we really appreciate this forge package and would like to keep using it in tangent with the rest of the nx plugins. Let me know if there is anything I can do to help :)

[tbinna]

Hmm, that's strange. Thanks for the reproduction repo. It fails on my end, too, but I am still unclear why. As you mentioned, I think it has to do with the webpack build in the nx-forge build executor.

Having said that, I suggest migrating to the package executor and configuring the build as a native Nx build. I have updated the repo and pushed a commit with an example here (the target default configs in nx.json are optional but allow you to run nx deploy forge-app which builds, packages and deploys the forge app): zjkipping/forge-nest-nx-plugins-issue@66cbd66

I haven't gotten around to changing the default in the app generator yet, but the plan is to eventually remove the existing build executor. You can read more about the idea of the package executor here: #86

Nx is moving really quickly, so it's not always that easy to keep pace. I am trying to keep the following example repo up to date with the current plugin best practice: https://github.com/toolsplus/nx-forge-examples

Please let me know if this solves the problem.

[zjkipping]

@tbinna Thanks for the quick response and the example commit on my repo! Really appreciate it :) I agree there has been a lot of churn in Nx recently and I completely understand that it isn't easy to keep up as a plugin maker. I will try out your idea when I have the time in our monorepo and report back here! Thanks again for all the help

[zjkipping]

Just did the migration to v5.2.0 and using esbuild for everthing + porting the resourceOutputPathMap over to the package executor options. Everything builds and works again! Thanks @tbinna for being so on top of things and going in a great direction with the plugin. Myself and the folks in my company's monorepo really appreciate it :)