Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mitration from nx 17.3.2 to 18.3.5 breaks compilation (input production env NX_MF_DEV_SERVER_STATIC_REMOTES) #27899

Closed
1 of 4 tasks
ekiliqua opened this issue Sep 12, 2024 · 4 comments · Fixed by #27929
Closed
1 of 4 tasks
Assignees
Labels
outdated scope: module federation Issues related to module federation support type: bug

Comments

@ekiliqua
Copy link

Current Behavior

The compilation broke after the update using "nx migrate --run-migrations".

Expected Behavior

It should compile.

GitHub Repo

No response

Steps to Reproduce

I'm not sure if the error actually originates from version 17, as I am migrating step by step from version 15. It's a monorepository with Angular applications. I believe I have pinpointed the problem, but I'm not sure if I need to configure something else or if I should simply remove the configuration that is added in a specific step of the migration.

In any case, it's possible that this migration step is causing the same issue for other users.

Nx Report

NX   Report complete - copy this into the issue template

Node   : 20.9.0
OS     : darwin-arm64
npm    : 10.1.0

nx                 : 18.3.5
@nx/js             : 18.3.5
@nx/jest           : 18.3.5
@nx/linter         : 18.3.5
@nx/eslint         : 18.3.5
@nx/workspace      : 18.3.5
@nx/angular        : 18.3.5
@nx/cypress        : 18.3.5
@nx/devkit         : 18.3.5
@nx/eslint-plugin  : 18.3.5
@nrwl/tao          : 18.3.5
@nx/web            : 18.3.5
@nx/webpack        : 18.3.5
typescript         : 5.4.5

Failure Logs

> nx serve customer-area --open --devRemotes="consola-monitorizacion"


> nx run customer-area:serve:development --open --devRemotes=consola-monitorizacion


 NX  Starting module federation dev-server for customer-area with 8 remotes


 NX  Building 7 static remotes...

/Users/xxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/@nx/angular/src/executors/module-federation-dev-server/lib/build-static-remotes.js:49
                throw new Error(`Remote failed to start. A complete log can be found in: ${remoteBuildLogFile}`);
                ^

Error: Remote failed to start. A complete log can be found in: /Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/.nx/cache/2024-09-12T18_41_05_920Z-build.log
    at ChildProcess.<anonymous> (/Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/@nx/angular/src/executors/module-federation-dev-server/lib/build-static-remotes.js:49:23)
    at ChildProcess.emit (node:events:514:28)
    at ChildProcess._handle.onexit (node:internal/child_process:294:12)

Node.js v20.9.0

========================================

And this is the content of the log file:

/Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/nx/src/hasher/native-task-hasher-impl.js:32
        const plans = this.planner.getPlansReference(tasks.map((t) => t.id), taskGraph);
                                   ^

Error: "production" is an invalid fileset.
All filesets have to start with either {workspaceRoot} or {projectRoot}.
For instance: "!{projectRoot}/**/*.spec.ts" or "{workspaceRoot}/package.json".
If "production" is a named input, make sure it is defined in nx.json.

    at NativeTaskHasherImpl.hashTasks (/Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/nx/src/hasher/native-task-hasher-impl.js:32:36)
    at InProcessTaskHasher.hashTasks (/Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/nx/src/hasher/task-hasher.js:53:50)
    at handleHashTasks (/Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/nx/src/daemon/server/handle-hash-tasks.js:30:56)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async handleResult (/Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/nx/src/daemon/server/server.js:107:16)
    at async handleMessage (/Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/nx/src/daemon/server/server.js:81:9)
    at async /Users/xxxxxxx/Documents/repos/xxxxxx-frontend-xxxxxx/node_modules/nx/src/daemon/server/server.js:45:9 {
  code: 'GenericFailure'

Package Manager Version

No response

Operating System

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

Additional Information

First of all, I apologize for my level of English; it’s not my native language.

I'm not sure if the error actually originates from version 17, as I am migrating step by step from version 15. It's a monorepository with Angular applications. I believe I have pinpointed the problem, but I'm not sure if I need to configure something else or if I should simply remove the configuration that is added in a specific step of the migration.

image

If I remove that configuration from the nx.json file, everything works correctly.

I think that configuration is added in one of these two migrations after running the command "nx migrate --run-migrations":

[...]

{
  "cli": "nx",
  "version": "18.0.0-beta.0",
  "description": "Add NX_MF_DEV_SERVER_STATIC_REMOTES to inputs for task hashing when '@nx/angular:webpack-browser' is used for Module Federation.",
  "factory": "./src/migrations/update-18-0-0/add-mf-env-var-to-target-defaults",
  "package": "@nx/angular",
  "name": "add-module-federation-env-var-to-target-defaults"
}

[...]

{
  "cli": "nx",
  "version": "18.1.1-beta.0",
  "description": "Ensure targetDefaults inputs for task hashing when '@nx/angular:webpack-browser' is used are correct for Module Federation.",
  "factory": "./src/migrations/update-18-1-1/fix-target-defaults-inputs",
  "package": "@nx/angular",
  "name": "fix-target-defaults-for-webpack-browser"
},

[...]

I think it’s related to this: #21390

Thank you

@Coly010
Copy link
Contributor

Coly010 commented Sep 16, 2024

This seems like it may be a caching issue or a stale Nx Graph, such that your removal of

{
  "env": "NX_MF_DEV_SERVER_STATIC_REMOTES"
}

is invalidating the stale graph and allowing for a rebuild, as {env: string} is a valid input.

The other thing to check is whether "production" is in your namedInputs in the nx.json.

@Coly010 Coly010 self-assigned this Sep 16, 2024
@Coly010 Coly010 added the scope: module federation Issues related to module federation support label Sep 16, 2024
@ekiliqua
Copy link
Author

Thank you for your response.

After reporting the issue, I continued testing and investigating. It seems that the error is caused because there is no configuration for "namedInputs". Shouldn't this be added automatically during the migration? If I remove these two lines, everything works perfectly:

image

And if we don't want to remove those two lines, we need to configure the namedInputs. I took these from a new project generated with nx@19. Shouldn't this be added automatically during the migration?:

image

Once I fixed that, I encountered a problem related to routing. The static servers for the applications that I haven't specified in "devRemotes" are not loading correctly. I've been reviewing the configuration of all the nx files, but I can't find the issue. I've seen related posts, but I can't seem to solve it... With a freshly generated project, routing works correctly, but after migrating the old project, it doesn't.

When I try to access any application, the same one always loads, regardless of which one I try to access. However, if I access an application specified in --devRemotes, that one works correctly...

Any ideas?

Thanks

@Coly010
Copy link
Contributor

Coly010 commented Sep 16, 2024

There is an issue with the migration but it is not that it needs to add those namedInputs, rather it should only add them if they exist.

Can you open a new issue for the remotes issue, with the version of Nx, and as much information as possible, including errors in the terminal and browser

FrozenPandaz pushed a commit that referenced this issue Sep 18, 2024
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->

## Current Behavior
<!-- This is the behavior we have today -->
Should use correct namedInputs in the migration instead of assuming
'production' is available.

## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the correct namedInputs based on what is listed in `nx.json`

## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->

Fixes #27899

(cherry picked from commit 0a8202a)
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 20, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated scope: module federation Issues related to module federation support type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants