After upgrade to 18.0.1", error External resources cannot be imported using a relative or absolute path @nx/enforce-module-boundaries

[LayMui]

Current Behavior

npx nx run ahua-design-system-react:lint I got this error

Linting "ahua-design-system-react"...

/Users/tohlaymui/dev/ahua-design-system-v3/libs/ahua-design-system-react/.storybook/ahua.theme.js 1:1 error External resources cannot be imported using a relative or absolute path @nx/enforce-module-boundaries

/Users/tohlaymui/dev/ahua-design-system-v3/libs/ahua-design-system-react/src/lib/combobox/combobox.tsx 53:64 warning Unexpected any. Specify a different type @typescript-eslint/no-explicit-any

/Users/tohlaymui/dev/ahua-design-system-v3/libs/ahua-design-system-react/src/lib/textarea/tests/textarea.test.js 62:

Expected Behavior

it should passed

GitHub Repo

No response

Steps to Reproduce

1. yarn install after upgrade all the following
2. "@nx/detox": "18.0.1", "@nx/devkit": "18.0.1", "@nx/eslint-plugin": "18.0.1", "@nx/jest": "18.0.1", "@nx/js": "18.0.1", "@nx/linter": "18.0.1", "@nx/react": "18.0.1", "@nx/react-native": "18.0.1", "@nx/rollup": "18.0.1",

also using the latest RN "react-native": "0.73.2",

Nx Report

NX   Report complete - copy this into the issue template

   Node   : 18.17.1
   OS     : darwin-x64
   yarn   : 1.22.21
   
   nx                 : 18.0.1
   @nx/js             : 18.0.1
   @nx/jest           : 18.0.1
   @nx/linter         : 18.0.1
   @nx/eslint         : 18.0.1
   @nx/workspace      : 18.0.1
   @nx/cypress        : 18.0.1
   @nx/detox          : 18.0.1
   @nx/devkit         : 18.0.1
   @nx/eslint-plugin  : 18.0.1
   @nx/react          : 18.0.1
   @nx/react-native   : 18.0.1
   @nx/rollup         : 18.0.1
   @nx/storybook      : 18.0.1
   @nrwl/tao          : 18.0.1
   @nx/vite           : 18.0.1
   @nx/web            : 18.0.1
   @nx/webpack        : 18.0.1
   typescript         : 5.1.6

Failure Logs

No response

Package Manager Version

yarn --version 1.22.21

Operating System

• [X] macOS
• [ ] Linux
• [ ] Windows
• [ ] Other (Please specify)

Additional Information

No response

[leosvelperez]

Thanks for reporting this!

We'll need more information to know if there's an issue or if this works as intended. Please provide a reproduction so we can troubleshoot it.

Note that the External resources cannot be imported using a relative or absolute path error is reported when a file in one of your projects imports another file that's not contained in any project (and it's not an npm package) using a relative or absolute path. If that's what you're seeing, it's the intended behavior.

[github-actions[bot]]

This issue has been automatically marked as stale because no reproduction was provided within 7 days. Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue. Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues. This issue will be closed in 21 days if a reproduction is not provided. If a reproduction has been provided, please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[raypatterson]

How would it work if you wanted to import a shared configuration from the root?

Example:

// libs/<project-name>/<project-tool>.config.ts

import sharedConfig from "../../configs/<project-tool>.shared";

Do you need to set up another Nx project for these and set up the boundaries or can you allow through some sort of ignore list?

[mfa-leanix]

How would it work if you wanted to import a shared configuration from the root?

@raypatterson, one way to go around that problem is to include the path alias for configs in root tsconfig, for example like this:

"paths": {
  "@my-org/configs": "./configs/*"
}

... then you can include the configs using the following, without any compile time errors:

import sharedConfig from "@my-org/configs/<project-tool>.shared";

[raypatterson]

How would it work if you wanted to import a shared configuration from the root?

@raypatterson, one way to go around that problem is to include the path alias for configs in root tsconfig, for example like this:

"paths": {
  "@my-org/configs": "./configs/*"
}

... then you can include the configs using the following, without any compile time errors:

import sharedConfig from "@my-org/configs/<project-tool>.shared";

Thanks for the suggestion @mfa-leanix !

I tried this and it worked for some tools that support TypeScript configuration files, and satisfied ESLint, but is seems that Vitest converts TS files to (M)JS at runtime and so the aliases no longer work.

Since I am not (currently) concerned with enforcing module boundaries between tools, I excluded the configuration files from the root and project-level ESLint configurations:

// .eslintrc.json
// libs/<project-name>/.eslintrc.json
    {
      "files": ["*.ts", "*.tsx"],
      "excludedFiles": ["**/<project-tool>.config.ts"], // <— 
      "rules": {
        "@nx/enforce-module-boundaries": [ ... ]

[github-actions[bot]]

This issue has been automatically marked as stale because no reproduction was provided within 7 days. Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue. Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues. This issue will be closed in 21 days if a reproduction is not provided. If a reproduction has been provided, please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[andirsun]

This solve the problem for me: In our case we have a library named libs/images so we store all the static svg there.

/// tsconfig.base.json
...
"paths": {
  "@foo/images/*": ["libs/images/*"],
}
...

So now I can import svg in any project or library and auto complete works out of the box

import {ReactComponent as GoogleIcon} from '@foo/images/google.svg'
...

[meeroslav]

Hi,

There are two ways to go about it:

• Use a dedicated library/project for such reusable configs (as @andirsun suggests) or
• Disable the check for that line using // eslint-disable-next-line @nx/enforce-module-boundaries

Both are fine and have their own pros and cons:

1. It's a convenient way to keep all shared configs in one place and affect all dependent projects when configs change BUT it will affect every project even if the change is not relevant

2. By disabling a single line, you surgically control where the limit of enforce boundaries is set, BUT this can lead to misuse if not controlled.

There is no silver bullet. You have to decide which option makes more sense to you and your team.

[github-actions[bot]]

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.