After replacing vite-tsconfig-paths by @nx/vite/plugins/nx-tsconfig-paths.plugin => app:serve target throws errors

[k-paxian]

Current Behavior

After replacing vite-tsconfig-paths by @nx/vite/plugins/nx-tsconfig-paths.plugin app:serve target throws errors

As a workaround I have to include this piece of config to the vite.config.ts of the app, which is feels and looks bad to me 🤷

    optimizeDeps: {
      exclude: [
        '@swc-node/register',
        '@angular-devkit',
        'webpack',
        '@nx/nx-win32-x64-msvc',
        '@nx/nx-darwin-arm64',
      ],
    },

NB: build:prod target works flawlessly, only serve target is throwing errors

Expected Behavior

There should be no errors in console, just like it was before drop-in replacement of the vite-tsconfig-paths by @nx/vite/plugins/nx-tsconfig-paths.plugin

GitHub Repo

No response

Steps to Reproduce

1. Upgrade to latest nx 16.6.0
2. Replace vite-tsconfig-paths by @nx/vite/plugins/nx-tsconfig-paths.plugin in vite.config.ts
3. nx run app:serve:development throws a lot of errors and fails to serve the app
4. nx run app:build:production works fine and produces app artifacts w/o errors

Nx Report

Node   : 16.15.0
   OS     : win32-x64
   yarn   : 1.22.19
   
   nx                 : 16.6.0
   @nx/js             : 16.6.0
   @nx/linter         : 16.6.0
   @nx/workspace      : 16.6.0
   @nx/cypress        : 16.6.0
   @nx/devkit         : 16.6.0
   @nx/eslint-plugin  : 16.6.0
   @nx/storybook      : 16.6.0
   @nrwl/tao          : 16.6.0
   @nx/vite           : 16.6.0
   typescript         : 5.1.6
   ---------------------------------------

Failure Logs

➜  Local:   http://localhost:4200/
  ➜  Network: http://192.168.0.169:4200/    
[vite-plugin-static-copy] Collected 2 items.
X [ERROR] Could not resolve "@angular-devkit/architect"

    node_modules/@nx/devkit/src/utils/convert-nx-executor.js:41:19:
      41 │     return require('@angular-devkit/architect').createBuilder(builderFunction);
         ╵                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@angular-devkit/architect" as external to exclude it from the bundle, which
  will remove this error. You can also surround this "require" call with a try/catch block to handle
  this failure at run-time instead of bundle-time.

X [ERROR] Could not resolve "webpack"

    node_modules/@nx/devkit/src/utils/module-federation/share.js:44:28:
      44 │     const webpack = require('webpack');
         ╵                             ~~~~~~~~~

  You can mark the path "webpack" as external to exclude it from the bundle, which will remove this
  error. You can also surround this "require" call with a try/catch block to handle this failure at
  run-time instead of bundle-time.

X [ERROR] Could not resolve "@angular-devkit/core"

    node_modules/nx/src/adapter/ngcli-adapter.js:5:23:
      5 │ const core_1 = require("@angular-devkit/core");
        ╵                        ~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@angular-devkit/core" as external to exclude it from the bundle, which will
  remove this error. You can also surround this "require" call with a try/catch block to handle this
  failure at run-time instead of bundle-time.

X [ERROR] Could not resolve "@angular-devkit/core/node"

    node_modules/nx/src/adapter/ngcli-adapter.js:6:23:
      6 │ const node_1 = require("@angular-devkit/core/node");
        ╵                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@angular-devkit/core/node" as external to exclude it from the bundle, which
  will remove this error. You can also surround this "require" call with a try/catch block to handle
  this failure at run-time instead of bundle-time.

X [ERROR] No known conditions for "./read-default-tsconfig" specifier in "@swc-node/register" package [plugin vite:dep-pre-bundle]

    node_modules/nx/src/plugins/js/utils/register.js:115:49:
      115 │         const { readDefaultTsConfig, } = require('@swc-node/register/read-default-tsconfig');
          ╵                                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  This error came from the "onResolve" callback registered here:

    node_modules/vite/node_modules/esbuild/lib/main.js:1292:20:
      1292 │       let promise = setup({
           ╵                     ^

    at setup (file:///C:/Users/omazuruk/Documents/GitHub/agent-ui/node_modules/vite/dist/node/chunks/dep-df561101.js:39921:19)
    at handlePlugins (C:\Users\omazuruk\Documents\GitHub\agent-ui\node_modules\vite\node_modules\esbuild\lib\main.js:1292:21)
    at buildOrContextImpl (C:\Users\omazuruk\Documents\GitHub\agent-ui\node_modules\vite\node_modules\esbuild\lib\main.js:978:5)
    at Object.buildOrContext (C:\Users\omazuruk\Documents\GitHub\agent-ui\node_modules\vite\node_modules\esbuild\lib\main.js:786:5)        
    at C:\Users\omazuruk\Documents\GitHub\agent-ui\node_modules\vite\node_modules\esbuild\lib\main.js:2186:68
    at new Promise (<anonymous>)
    at Object.context (C:\Users\omazuruk\Documents\GitHub\agent-ui\node_modules\vite\node_modules\esbuild\lib\main.js:2186:27)
    at Object.context (C:\Users\omazuruk\Documents\GitHub\agent-ui\node_modules\vite\node_modules\esbuild\lib\main.js:2026:58)
    at prepareEsbuildOptimizerRun (file:///C:/Users/omazuruk/Documents/GitHub/agent-ui/node_modules/vite/dist/node/chunks/dep-df561101.js:45967:35)

X [ERROR] Could not resolve "@angular-devkit/architect"

    node_modules/nx/src/adapter/ngcli-adapter.js:37:38:
      37 │         const { Architect } = require('@angular-devkit/architect');
         ╵                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@angular-devkit/architect" as external to exclude it from the bundle, which
  will remove this error. You can also surround this "require" call with a try/catch block to handle
  this failure at run-time instead of bundle-time.

X [ERROR] Could not resolve "@angular-devkit/schematics/tools"

    node_modules/nx/src/adapter/ngcli-adapter.js:112:33:
      112 │     const NodeWorkflow = require('@angular-devkit/schematics/tools').NodeWorkflow;
          ╵                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@angular-devkit/schematics/tools" as external to exclude it from the
  bundle, which will remove this error. You can also surround this "require" call with a try/catch
  block to handle this failure at run-time instead of bundle-time.

X [ERROR] Could not resolve "@angular-devkit/schematics"

    node_modules/nx/src/adapter/ngcli-adapter.js:118:63:
      118 │         registry: new core_1.schema.CoreSchemaRegistry(require('@angular-devkit/schematics').formats.standardFormats),
          ╵                                                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@angular-devkit/schematics" as external to exclude it from the bundle,
  which will remove this error. You can also surround this "require" call with a try/catch block to
  handle this failure at run-time instead of bundle-time.

X [ERROR] Could not resolve "@angular-devkit/architect/node"

    node_modules/nx/src/adapter/ngcli-adapter.js:722:140:
      722 │ ...ngularWorkspaceNodeModulesArchitectHost, } = yield Promise.resolve().then(() => require('@angular-devkit/architect/node')); 
          ╵                                                                                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    

  You can mark the path "@angular-devkit/architect/node" as external to exclude it from the bundle,
  which will remove this error. You can also surround this "require" call with a try/catch block to
  handle this failure at run-time instead of bundle-time.

X [ERROR] No loader is configured for ".node" files: node_modules/@nx/nx-win32-x64-msvc/nx.win32-x64-msvc.node

    node_modules/nx/src/native/index.js:66:36:
      66 │             nativeBinding = require('@nx/nx-win32-x64-msvc')
         ╵                                     ~~~~~~~~~~~~~~~~~~~~~~~

X [ERROR] Could not resolve "@swc/wasm"

    node_modules/@swc/core/index.js:70:35:
      70 │         fallbackBindings = require('@swc/wasm');
         ╵                                    ~~~~~~~~~~~

  You can mark the path "@swc/wasm" as external to exclude it from the bundle, which will remove
  this error. You can also surround this "require" call with a try/catch block to handle this
  failure at run-time instead of bundle-time.

X [ERROR] No loader is configured for ".node" files: node_modules/@swc/core-win32-x64-msvc/swc.win32-x64-msvc.node

    node_modules/@swc/core/binding.js:68:48:
      68 │                         nativeBinding = require('@swc/core-win32-x64-msvc');
         ╵                                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~

Operating System

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

Additional Information

No response

[k-paxian]

@barbados-clemens probably you could remember some context after this PR #17844

[barbados-clemens]

@k-paxian do you have a repo I can test with?
none of my local testing shows serve failing, but there are some cases where serve won't use prebuilt artifacts which should be fixed in #18477. Still have to do some testing to confirm.

But unaware of this issue specifically. But it shouldn't actually matter since those deps aren't other nx projects but in the node_modules which vite itself should be able to understand?

Also unsure why the angular deps are trying to be brought in as you're project doesn't look to be using angular from the nx report.

[k-paxian]

I'll try to mock it up on stackbliz later this week. My wild guess is that the node process which is executing vite.config.ts pulls in too much stuff via that new plugin import. But we'll see 🙈

[barbados-clemens]

the plugin only resolved values within the tsconfig.base.json at the root of the repo so I would be surprised, but honestly I've seen wilder stuff happen so it's possible some case I didn't consider when writing.

[k-paxian]

ok, sorry folks, that's might be not the nx fault at all. 🤦

I did a bit deeper dive into that, and it appears that vite has a dependency optimization routine
which is actually scanning the node_modules in an auto dependency discovery mode
https://vitejs.dev/guide/dep-pre-bundling.html#automatic-dependency-discovery

And because the default option is to optimize dev mode only, that's explains why build:prod is fine 😄
https://vitejs.dev/config/dep-optimization-options.html#optimizedeps-disabled

All in all, after importing new plugin, this auto dependency discovery thingy discovered some absolutely unrelated
modules to be optimized and cached to .vite cache. So this is a purely vite issue

And for my case I'd go with that vite config for now, which is looks and feels much better than listing all the random packages to exclude 😄

    optimizeDeps: {
       disabled: true
    },

until they will fix that experimental 💀 auto optimization process

Thank you for a great NX stuff ❤️ , sorry for borrowing your attention w/o real need

[barbados-clemens]

no worries, this is helpful information that I didn't know either. Appreciate you digging into it and finding that stuff out!

[k-paxian]

Unfortunately

    optimizeDeps: {
       disabled: true
    },

was not a viable option, so I ended up with those ugly list of ever growing excludes 😞 and disabled: 'build' for visibility

    optimizeDeps: {
      disabled: 'build',
      exclude: [
        '@swc-node/register',
        '@angular-devkit',
        'webpack',
        '@nx/nx-win32-x64-msvc',
        '@nx/nx-darwin-arm64',
      ],
    },

vite treats those packages as CJS-only and desperately trying to convert them to ESM, BUT:

'@swc-node/register', - it exists in my local `node_modules` and contains an ESM bundle in fact, but in a different/non standard way 😄  via "exports" section of `package.json`
'@angular-devkit', - doesn't even exists in my local `node_modules` 🤷 
'webpack', - doesn't even exists in my local `node_modules` 🤷 
'@nx/nx-win32-x64-msvc', - exists on my windows os local `node_modules`, but it's a binary/native package, it's nor CJS nor EMS at all
'@nx/nx-darwin-arm64', - exists on my mac os local `node_modules`, but it's a binary/native package, it's nor CJS nor EMS at all

Looks like plenty of edge cases for vite to handle automagically 😄

• if it doesn't exists - do not optimize thin air
• if it is a binary/native package - do not try to optimize binary stuff 😄
• if it seems like not having ESM support declared properly and it's not referenced in the project you are trying to bundle up, don't try to optimize it

[barbados-clemens]

@k-paxian does this happen if you switch back to vite-tsconfig-paths plugin?

[k-paxian]

No, it doesn't happen with the old plugin

[barbados-clemens]

Then it must be something specific to how we are handling things. I'll have to dig into the vite-tsconfig-paths plugin to see what we are missing. Explains why that plugin is more complex than I expected when first looking at it. 😅

[k-paxian]

But those extra dependencies from the exclude list are clear false positives and imho should be handled by vite directly or indirectly by providing a way to pass some custom logic in vite.config or by plugin interface allowing to alter the list of targets for optimization.

[barbados-clemens]

Hey I was looking into this and still unsure what is happening. do you have a repo I can look? I'm trying to get the same errors but not able to.

[k-paxian]

@barbados-clemens
interestingly though, it doesn't happen anymore in our codebase 🤷 I've traced down the commit which is flipping the behaviour, now i'm trying to revert file by file to get to the root cause 😄

[k-paxian]

Finally, here is the minimal reproduction
https://stackblitz.com/edit/vitejs-vite-jecvhf?file=package.json,src%2FApp.vue&terminal=dev

<script setup lang="ts">
// This import is causing vite to fail serve in dev mode
import { DependencyType, type ProjectGraph, type ProjectGraphProcessorContext, type ProjectsConfigurations } from '@nx/devkit'
//
</script>

It has nothing to do with the plugin @nx/vite/plugins/nx-tsconfig-paths.plugin,
it was a coincidence - in one commit we had this plugin swap + that import above appeared in the .vue component.

In an essence, whatever you'd try to import from @nx/devkit inside the vue component with typescript, you have a 💥 in a serve/dev mode 😄

It makes a little sense maybe to import stuff from @nx/devkit directly, but we had it imported indirectly, via additional npm package, which exports nx graph plugin and as well imports some stuff from @nx/devkit. Not sure which bucket to put this issue then? 🤷 any thoughts from here? @barbados-clemens

[jaysoo]

@k-paxian What is the use case for importing from @nx/devkit in a component or production code? Generally, it wouldn't work because devkit is meant to be used inside Nx plugins. If you still need the import, would adding // @vite-ignore help?

[jaysoo]

It doesn't appear to be an Nx issue, can we close this? @nx/devkit should not be imported into production code.

[k-paxian]

Well, @jaysoo it actually doesn't specific to @nx/devkit exclusively, it affects literally all nx plugins. So you wanna say it's never ever needed to import anything from any nx plugin?

simple const import is affected as well

import { jsdomVersion } from '@nx/vite'

in other words we are not able to import any npm package which has @nx/devkit in dependencies list.

Despite that, I agree it's more of vite issue than nx

[jaysoo]

Yes, it applies to all @nx/* plugins as they are meant to be used only for development. The only places where we expect @nx/* to be use are in config files (e.g. vite.config.ts, next.config.js, jest.config.ts, etc.), and these are only used during test/build not prod runtime.

Is there an use-case where you want to import those plugins in production code?

[k-paxian]

In our use-case we have an npm package which contains our own nx plugins + some typescript types to be used in the production code. And we are not able to have them both in one package, we are forced to split those onto separate packages to avoid such issue 🤷

Also we need to have those types to be imported by the (e.g. vite.config.ts, next.config.js, jest.config.ts, etc.), AND production code simultaneously.

Having separate npm package to share few types across configs and production app sounds like overkill to me 😞

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.