Remix Build uses Classic Compiler over Vite when specifying build target

[cyberarc8]

Current Behavior

When trying to configure the options of @nx/remix:build executor, Vite Compiler is not used.

We need to generate a package.json for deployment with server deps.

With

 "targets": {
    "build": {
      "executor": "@nx/remix:build",
      "outputs": ["{options.outputPath}"],
      "options": { "outputPath": "dist/apps/myapp" },
      "generatePackageJson": true
    }
  }

the build is using Classix Remix Compiler, even though the project was just created with vite.config.ts and without remix.config.js.:

$ npx nx build myapp

> nx run myapp:build

 info  building... (NODE_ENV=production)
 warn  Fetcher persistence behavior is changing in React Router v7
┃ You can use the `v3_fetcherPersist` future flag to opt-in early.
┃ -> https://remix.run/docs/en/2.13.1/start/future-flags#v3_fetcherPersist
┗
 warn  Route discovery/manifest behavior is changing in React Router v7
┃ You can use the `v3_lazyRouteDiscovery` future flag to opt-in early.
┃ -> https://remix.run/docs/en/2.13.1/start/future-flags#v3_lazyRouteDiscovery
┗
 warn  Relative routing behavior for splat routes is changing in React Router v7
┃ You can use the `v3_relativeSplatPath` future flag to opt-in early.
┃ -> https://remix.run/docs/en/2.13.1/start/future-flags#v3_relativeSplatPath
┗
 warn  Data fetching is changing to a single fetch in React Router v7
┃ You can use the `v3_singleFetch` future flag to opt-in early.
┃ -> https://remix.run/docs/en/2.13.1/start/future-flags#v3_singleFetch
┗
 warn  The format of errors thrown on aborted requests is changing in React Router v7
┃ You can use the `v3_throwAbortReason` future flag to opt-in early.
┃ -> https://remix.run/docs/en/2.13.1/start/future-flags#v3_throwAbortReason
┗
 info  built (6.6s)

————————————————————————————————————————————————————————————

 NX   Successfully ran target build for project myapp

Expected Behavior

Configuring executors options doesnt change the Build Tool.

With "targets": {} the Build is correctly based on Vite:

$ npx nx build myapp

> nx run myapp:build

> remix vite:build

vite v5.4.14 building for production...
transforming...
✓ 85 modules transformed.
rendering chunks...
computing gzip size...
build/client/.vite/manifest.json                1.07 kB │ gzip:  0.30 kB
build/client/assets/root-BHJYanvM.js            1.77 kB │ gzip:  1.01 kB
build/client/assets/entry.client-CHpbgU94.js    3.73 kB │ gzip:  1.43 kB
build/client/assets/jsx-runtime-D5FwP9M8.js     8.11 kB │ gzip:  3.05 kB
build/client/assets/_index-ctgGTa4I.js         24.34 kB │ gzip:  6.20 kB
build/client/assets/components-UFyj0GOY.js    247.43 kB │ gzip: 79.88 kB
✓ built in 4.36s
vite v5.4.14 building SSR bundle for production...
transforming...
✓ 6 modules transformed.
rendering chunks...
build/server/.vite/manifest.json   0.15 kB
build/server/index.js             42.30 kB
✓ built in 276ms

————————————————————————————————————————————————————————————

 NX   Successfully ran target build for project myapp (13s)

GitHub Repo

No response

Steps to Reproduce

1. npx create-nx-workspace@latest acme --preset=apps
2. npx nx add @nx/remix
3. npx nx g @nx/remix:app apps/myapp
4. running npx nx build myapp at this point creates a build folder of correct Vite structure (build/client & build/server) in apps/myapp
5. add build target in apps/myapp/project.json

{
  "name": "myapp",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "apps/myapp",
  "projectType": "application",
  "tags": [],
  "// targets": "to see all targets run: nx show project myapp --web",
  "targets": {
    "build": {
      "executor": "@nx/remix:build",
      "outputs": ["{options.outputPath}"],
      "options": { "outputPath": "dist/apps/myapp" },
      "generatePackageJson": true
    }
  }
}

4. running npx nx build myapp now ->build is not based on vite, it creates apps/myapp/public/build and apps/myapp/build

Nx Report

npx nx report

 NX   Report complete - copy this into the issue template

Node           : 22.9.0
OS             : win32-x64
Native Target  : x86_64-windows
npm            : 10.8.3

nx                     : 20.3.3
@nx/js                 : 20.3.3
@nx/eslint             : 20.3.3
@nx/workspace          : 20.3.3
@nx/devkit             : 20.3.3
@nx/module-federation  : 20.3.3
@nx/react              : 20.3.3
@nx/remix              : 20.3.3
@nx/vite               : 20.3.3
@nx/web                : 20.3.3
typescript             : 5.6.3
---------------------------------------
Registered Plugins:
@nx/remix/plugin

Failure Logs

Package Manager Version

No response

Operating System

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

Additional Information

No response

[Evanion]

Yea, we had the same issue.
We ended up with a workaround

FROM node:lts-alpine AS production-dependencies-env
COPY ./package.json package-lock.json /app/
COPY .npmrc /root/
WORKDIR /app
RUN npm ci --omit=dev

FROM node:lts-alpine
ENV NODE_ENV=production
COPY --from=production-dependencies-env /app/node_modules /app/node_modules
COPY ./apps/my-app/build /app/build
WORKDIR /app
CMD ["./node_modules/.bin/remix-serve", "./build/server/index.js"]

Basically, we build the app with nx build <app> ( or in our case, running nx affected container, tha depends on the build target). We then run the dockerfile, that starts with pulling in the global package.json, and installing only the prod dependencies, and we then copy over the previously built artifact.

The downside is that if you have a large monorepo, with a lot of unrelated dependencies to the project that your building at the time, there will be a bloated docker image. It would have been a lot better if we could generate a properly scoped package.json.

[Coly010]

Hey @cyberarc8 !

This is expected at this moment in time and not a bug.

Vite support for Remix is provided by the @nx/remix/plugin using Inferred Tasks, not via the @nx/remix:executor. Switching to use that will mean you're going back to using the classic compiler.

What we had generated for you OTTB should have been fine to build with Vite.
If the issue is then that you didn't have a package.json that you could use, there are vite plugins that can help with that. you can create and maintain a package.json at the project root and use https://www.npmjs.com/package/vite-plugin-copy to copy it to your output directory if it is required.

[cyberarc8]

Hey @Coly010 !

Thank you for your reply, I'm not sure if I fully understand you. How would we maintain a package.json at project root - doesn't that interfere with how Nx and Single Version Policy work? How can we keep it in sync with the root package.json? My understanding was that the generatePackageJson option is there to avoid this scenario of two conflicting package.json files.

Please let me know if I'm missing something.

[Coly010]

If you don't run npm install in the project root, then it'll fallback to the node_modules at the workspace, so it's fine to have a package.json in the project root.
If you use package manager workspaces such as PNPM/Yarn/NPM workspaces, then it also helps manage dependencies. But it's not a requirement to do that.

The @nx/dependency-checks eslint rule will also help you keep your package.json in line.
https://nx.dev/nx-api/eslint-plugin/documents/dependency-checks#dependency-checks-rule