nx: fileReplacements no longer work with react and webpack

Current Behavior

When building a react app using @nx/webpack:webpack, file replacements are no longer working. Looks like this commit https://github.com/nrwl/nx/commit/395eb70336cb1346548705d7c41d896b4a6c6cbb is the culprit

Expected Behavior

file replacements should work when building or serving a react application

GitHub Repo

No response

Steps to Reproduce

  1. Set up a nx workspace with a react app.
  2. Create a production config using a file replacement
  3. Build the production config
  4. Notice that the file replacements do not work

Nx Report

Node   : 20.9.0
   OS     : darwin-arm64
   yarn   : 3.6.4
   
   nx                 : 17.1.1
   @nx/js             : 17.1.1
   @nx/jest           : 17.1.1
   @nx/linter         : 17.1.1
   @nx/eslint         : 17.1.1
   @nrwl/linter       : 15.9.2
   @nx/workspace      : 17.1.1
   @nx/cypress        : 17.1.1
   @nx/devkit         : 17.1.1
   @nx/esbuild        : 17.1.1
   @nx/eslint-plugin  : 17.1.1
   @nx/node           : 17.1.1
   @nx/react          : 17.1.1
   @nx/storybook      : 17.1.1
   @nrwl/tao          : 17.1.1
   @nx/vite           : 17.1.1
   @nx/web            : 17.1.1
   @nx/webpack        : 17.1.1
   typescript         : 5.2.2

Failure Logs

No response

Package Manager Version

No response

Operating System

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

Additional Information

No response

About this issue

  • Original URL
  • State: closed
  • Created 8 months ago
  • Reactions: 24
  • Comments: 26 (5 by maintainers)

Most upvoted comments

👋 Hey Nx team,

I want to express the urgency and critical nature of this issue. The problem with file replacements not working in React or Nestjs applications using @nx/webpack:webpack, as highlighted in this thread, is having a severe impact on multiple users, hindering their build and serve processes.

🔍 Observations:

  • File replacements are failing after commit 395eb70.
  • Downgrading to 17.0.* resolves the issue for some users.
  • Impact extends to outputPath, webpack file paths, and other related concerns.

🌐 Community Impact:

  • Blocking deployments for users in live environments.
  • Reverting to older versions as a temporary solution.
  • High risk for projects dependent on correct file replacements.

👥 Community Confirmation:

  • Multiple users have confirmed the issue.
  • Impact extends to various projects, including React and Nest applications.

📅 Timeline:

  • The issue has been open for two weeks without a resolution.
  • Users are seeking updates and an ETA on the fix.

🙏 Request:

  • Prioritize the resolution of this critical bug.
  • Provide guidance on potential workarounds.
  • Keep the community updated on the progress.

This bug is affecting a substantial number of users and has become a blocker for those relying on the latest Nx versions in production. Addressing this promptly will have a positive impact on the community and their projects.

Thank you for your attention to this matter.

@jaysoo , any update? It’s critical blocker for use last NX versions on live environments

@AgentEnder Any ETA on the fix?

I am experiencing the same thing, just with a Nest app.

Seems like it works if using relative paths like this

                    "fileReplacements": [
                        {
                            "replace": "./environments/environment",
                            "with": "./environments/environment.master.ts"
                        }
                    ]

The same is happening for me after migrating from nx 17.0.3 to 17.1.1

Nx Report

Node   : 18.18.2
   OS     : win32-x64
   npm    : 9.8.1
   
   nx                 : 17.1.1
   @nx/js             : 17.1.1
   @nx/jest           : 17.1.1
   @nx/linter         : 17.1.1
   @nx/eslint         : 17.1.1
   @nx/workspace      : 17.1.1
   @nx/cypress        : 17.1.1
   @nx/devkit         : 17.1.1
   @nx/eslint-plugin  : 17.1.1
   @nx/node           : 17.1.1
   @nx/react          : 17.1.1
   @nx/rollup         : 17.1.1
   @nx/storybook      : 17.1.1
   @nrwl/tao          : 17.1.1
   @nx/web            : 17.1.1
   @nx/webpack        : 17.1.1
   typescript         : 5.2.2
   ---------------------------------------
   Community plugins:
   @nxext/capacitor   : 17.0.1
   @nxext/ionic-react : 17.0.1

same issue. Downgrading to 17.0.3 fixed it for me

I believe we have encountered this issue upon migrating from nx@17.02 to nx@17.1.2 with a NodeJS application built with @nrwl/webpack:webpack and served with @nx/js:node, as environment variable values do not appear to be available at runtime unless the values are manually entered into environment.ts.

 >  NX   Report complete - copy this into the issue template

   Node   : 18.16.1
   OS     : darwin-arm64
   npm    : 9.5.1
   
   nx             : 17.1.2
   @nx/js         : 17.1.2
   @nx/jest       : 17.1.2
   @nx/linter     : 17.1.2
   @nx/eslint     : 17.1.2
   @nx/workspace  : 17.1.2
   @nx/angular    : 17.1.2
   @nx/cypress    : 17.1.2
   @nx/devkit     : 16.5.1
   @nx/node       : 17.1.2
   @nrwl/tao      : 17.1.2
   @nx/web        : 17.1.2
   @nx/webpack    : 17.1.2
   typescript     : 5.2.2
   ---------------------------------------
   Community plugins:
   apollo-angular : 5.0.2
   ---------------------------------------
   The following packages should match the installed version of nx
     - @nx/devkit@16.5.1
     - @nrwl/devkit@16.5.1

(@nx/devkit & @nrwl/devkit are not in our package.json, so I’m not sure why they keep showing up even after deleting node_modules and running npm install.)

I think we’re waiting on the release of nx@17.2.0, @jacqueslareau, as a fix closing the issue was merged into nx@17.20-beta.8, though I have not personally tested.

Seems like it works if using relative paths like this

                    "fileReplacements": [
                        {
                            "replace": "./environments/environment",
                            "with": "./environments/environment.master.ts"
                        }
                    ]

So it appears this format works IF your import looks like import {} from './environments/environment'; however if you use a barrel in environments/index.ts this format doesn’t work and you need to use something like this.

            {
              "replace": "./environment",
              "with": "./environment.prod.ts"
            },

Also note: The replace does NOT have .ts

Observed the same here: running build with @nx/webpack executor results in artifacts getting created under duplicate “dist” folder. ( e.g. C:\my_repo\dist\dist\libs.… instead of C:\my_repo\dist\libs.…)

Note: In our case, it could be due to the fact that we are also using the webpack CopyPlugin

Like mention in the issue 20253, relative paths are no more working. Absolute paths does, but it is not something that I can commit. Thanksfully I’m not yet in production …

I can confirm this is an issue. Downgrading to 17.0.* fixed it for me.