[WORKSPACE] Bit status how to not be aware of some import s

[MatthD]

Description

In our project (backend) we are using aliased to import files, that means not relative.
So our packages/core/index.ts folder can import something via import {} from '@ava/core/helper'

This lead bit status to indicated us we have issue with import, causing a lot of noises and prevent us to see the real missing dependencies.

How could we deal with that ?

Same question but seems when we don't import main file it's not ok too, we have packagesfolder that just represent a group of file that could be imported directly by our backend

Specifications

• Bit version: 1.6.126
• Node version: 20.11.0
• npm / yarn version: 10.2.4
• Platform: Mac0s 14.4.1
• Bit compiler (include version): pnpm

Context and additional information

[itaymendel]

it is really not recommended for components to import internal files or self-refer to the package name. this may cause compilation issues down the line.

if you want Bit to stop complaining on some issues, you can add a similar config to your worksapce.jsonc

"teambit.component/issues": {
    "ignoreIssues": [
      "CircularDependencies",
      "DuplicateComponentAndPackage"
    ]
  },

all possible issues are here - https://github.com/teambit/bit/tree/master/components/component-issues

[GiladShoham]

In addition to what @itaymendel wrote.
It's not recommended to use aliases, as these imports are context aware. Aka needs a tsconfig to set these aliases which make the components not portable.
Any component is available to be consumed via its package name (even before export/publishing).
This is also more standard way for import as it's not tool specific.
So please use package names.

[MatthD]

Hello ! Sorry and thanks for the informations but in fact we were looking for a backend solution of monorepo workspace management, and found BIT on the pnpm docs

It's not very clear for us what our apps and packages can be related to BIT, but if we understood correctly anything can be a component.
A good way in dev to avoid relative import and help moving/maintain is to use TS path aliases.

So does that means Bit is not for backend typescript project ?

In fact we are using packages name. but it's not very suitable when we are dealing in terme of dev-experience, we need to re-run bit link/bit compile on every new file, and removed/renamed files are still visible, so TS alias in dev are more suitable, we just have TS path alias overriding the scope/name.

In fact to resume we just need Bit as a workspace dependencies management (and it shine wth bit status, bit show ...), not really for component compile .. (we will continue to compile our backend app via TSC etc ..)

[itaymendel]

Bit doesn't support ts paths between components, as they are related to the specific file system structure of the workspace, and locks you to a specific FS structure.

In bit, each component is automatically linked via node-modules, and you are expected to use these module links.
the question is on your backend developer is mostly "what is a component", as in bit, if you need to share code between your backends the goal is to move it to it's own component/library, and not import from internal files.