Error: EEXIST: file already exists, mkdir ../../monorepo/apps/tasks/dist

[VictorPulzz]

Describe the bug

I used the simplest example from the rsbuild repository https://github.com/rspack-contrib/rspack-examples/tree/main/rsbuild/module-federation-enhanced. And it gives an error:
Error: EEXIST: file already exists, mkdir '/monorepo/apps/tasks/dist'
at createError (/monorepo/node_modules/.pnpm/@rsbuild[email protected]/node_modules/@rsbuild/core/compiled/rsbuild-dev-middleware/index.js:1814:23)
at Volume.mkdirBase (/monorepo/node_modules/.pnpm/@rsbuild[email protected]/node_modules/@rsbuild/core/compiled/rsbuild-dev-middleware/index.js:3470:42)
at Immediate. (/monorepo/node_modules/.pnpm/@rsbuild[email protected]/node_modules/@rsbuild/core/compiled/rsbuild-dev-middleware/index.js:2424:31)
at process.processImmediate (node:internal/timers:483:21) {
code: 'EEXIST',
path: '/monorepo/apps/tasks/dist'
}

This happens when adding any changes, hmr is triggered and this error appears.

I'm afraid to imagine what will happen when I start adding more packages and the project size increases:D

My config rsbuild.config.ts:

import {defineConfig} from '@rsbuild/core';
import {pluginReact} from '@rsbuild/plugin-react';
import {pluginSass} from '@rsbuild/plugin-sass';
import {pluginModuleFederation} from "@module-federation/rsbuild-plugin";

export default defineConfig({
  plugins: [
    pluginReact(),
    pluginSass(),
    pluginModuleFederation({
      name: 'tasks',
      exposes: {
        './button': './src/Button.tsx',
      },
      shared: ['react', 'react-dom'],
    }),
  ],
  server: {
    port: 3051
  },
  output: {
    distPath: {
      // root: platformPathBuild('tasks'),
      image: 'assets',
      svg: 'assets',
      font: 'assets',
      media: 'assets',
    },
  },
  html: {
    template: './template.html',
  },
});

Reproduction

https://github.com/rspack-contrib/rspack-examples/tree/main/rsbuild/module-federation-enhanced

Used Package Manager

pnpm

System Info

System:
    OS: macOS 14.0
    CPU: (8) arm64 Apple M1
    Memory: 100.97 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.18.1 - ~/.nvm/versions/node/v20.18.1/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v20.18.1/bin/yarn
    npm: 10.8.2 - ~/.nvm/versions/node/v20.18.1/bin/npm
    pnpm: 9.15.0 - ~/.nvm/versions/node/v20.18.1/bin/pnpm
    Watchman: 2023.05.08.00 - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 131.0.6778.140
    Safari: 17.0

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[zhoushaw]

@VictorPulzz Let me see.

[windivi]

it's ok?

[sobaniitekurete]

oh. this bug fixed now?

is it same problem

[ Module Federation Dev Server ] Success Federated types created correctly
Error: EEXIST: file already exists, mkdir 'my-workspace\dist'
    at createError (my-workspace\node_modules\@rsbuild\core\compiled\rsbuild-dev-middleware\index.js:1814:23)
    at Volume.mkdirBase (my-workspace\node_modules\@rsbuild\core\compiled\rsbuild-dev-middleware\index.js:3470:42)
    at Immediate.<anonymous> (my-workspace\node_modules\@rsbuild\core\compiled\rsbuild-dev-middleware\index.js:2424:31)
    at process.processImmediate (node:internal/timers:478:21) {
  code: 'EEXIST',
  path: 'my-workspace\\dist'
}

[lozunoff]

I have a similar problem in my project. When I run the project in dev mode, the /dist directory is automatically generated with the files .dev-server.zip, @mf-types.d.ts and @mf-types.zip for Remote Type Hints. After that, when I edit my components, this directory tries to be overwritten with new types and this leads to an error.

[LeonieNFarmer]

I'm also having this issue. I am trying to update my monorepo from using webpack to rspack and am finding that the hmr doesn't work. As soon as I make any code change I see this in the console:
Type-checking in progress... No errors found. [ Module Federation Dev Server ] Success Federated types created correctly [ Module Federation Dev Server ] Success Federated types created correctly Error: EEXIST: file already exists, mkdir '/home/vagrant/Projects/foo/dist/apps/example/remote1' at createError (/home/vagrant/Projects/foo/node_modules/webpack-dev-middleware/node_modules/memfs/lib/node/util.js:152:19) at Volume.mkdirBase (/home/vagrant/Projects/foo/node_modules/webpack-dev-middleware/node_modules/memfs/lib/volume.js:1317:42) at Immediate.<anonymous> (/home/vagrant/Projects/foo/node_modules/webpack-dev-middleware/node_modules/memfs/lib/volume.js:377:33) at process.processImmediate (node:internal/timers:491:21) { code: 'EEXIST', path: '/home/vagrant/Projects/foo/dist/apps/example/remote1' } ^C[ Module Federation Dev Server ] Info remote1 Process(34219) SIGINT, mf server will exit...

[lozunoff]

I found out that hmr for remote type hints does not work because in the dts-plugin plugin, when calling mkdir functions, the option allowing overwriting of an existing directory ({ recursive: true }) is not passed. If this option is added, then hmr starts working and the error goes away. Created a PR with this change.

[lozunoff]

I continued to investigate this problem and found out that the error began to appear with version 0.8.4. I rolled back the packages @module-federation/enhanced and @module-federation/rsbuild-plugin to version 0.8.3 - the error disappeared, hmr works fine.

[lozunoff]

@ScriptedAlchemy @2heal1 please pay attention to this issue.
Presumably, the problems started after this commit.
As I wrote above, the problem is partially solved by enabling the recursive option for mkdir functions. After that, the error disappears and the dist directory with the type files is recreated without problems, but it seems that there is another problem with hmr in this scenario.
I noticed that in this case, every time you edit files with types in a remote application, the host application is loaded with the previous version of the type changes, not the latest one. To get the current version of types via hmr, you first need to change the types in the remote application, and then make any other change in the components of the remote application, and after that, the current version of the types is loaded in the host application.
At the same time, in version 0.8.3, none of the above problems are present and everything works fine.

[ScriptedAlchemy]

If you know if a fix. Feel free to send a PR. I'm out of the country so it may take me a while to look at it without a machine. But seems simple enough to debug and PR

[Nondukishor]

it is fixed?

[ScriptedAlchemy]

PR has failing tests so can't merge it till those pass.