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

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

Closed
MatthD opened this issue Apr 23, 2024 · 4 comments
Closed

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

MatthD opened this issue Apr 23, 2024 · 4 comments

Comments

@MatthD
Copy link

MatthD commented Apr 23, 2024

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

Capture d’écran 2024-04-23 à 17 34 20

@itaymendel
Copy link
Contributor

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
Copy link
Member

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
Copy link
Author

MatthD commented Apr 23, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants