Feature request: distribute types in a separate package eg. @types/react-native-fast-image

[samzmann]

TLDR: I would like to have access to the react-native-fast-image types in a separate package, distributed on npm, called for example @types/react-native-fast-image. This @types package would follow the same version number as the main package.

---

Explanation: I'm working in a monorepo where a shared package ("image-tools") and various apps ("App1", "App2", etc) all have the react-native-fast-image dependency. Dependencies are managed in two places:

• at the top level for shared packages
• at the app level for apps (because I ran into too many problems trying to manage native deps at the repo level)

  repo/
  ├─ node_modules/
  ├─ package.json
  ├─ packages/
  │  ├─ image-tools/
  │  │  ├─ package.json // dependencies installed in repo/node_modules
  ├─ apps/
  │  ├─ App1/
  │  │  ├─ node_modules/
  │  │  ├─ package.json // dependencies installed in App1/node_modules

The image-tools shared package is only ever used in an app, and has react-native-fast-image listed as a peer dependency. So image-tools can get away with just requiring the type definitions from RNFI.

Now however, if I want to use RNFI types in image-tools, I have to install RNFI as a dependency or devDependency. Then, I run into an error Tried to register two views with the same name FastImageView.

My solution to this would be to have image-tools only depend on the RNFI types, and have the apps depend on the full RNFI. Therefore I would really like to have a separate @types/react-native-fast-image package.

But: If you have any better solution to suggest, I am very happy to hear it!

Thx 😊

[hatem-72]

For your usage I think simply declaring your own react-native-fast_image.d.ts at the app level should be fine.

declare module 'react-native-fast_image' {
  // Paste here the content of node_modules/react-native-fast_image/dist/index.d.ts
}

Then no need to add react-native-fast-image as dependency in your apps.

[samzmann]

I already thought of that and tried, but I see two problems:

1. I would need to remember to manually update this file
2. .d.ts file have global project scope. So when I was navigating to definition from a file in App1, it would send me to react-native-fast_image.d.ts instead of node_modules/react-native-fast_image/dist/index.d.ts. Maybe there is some config I can use to limit the scope of react-native-fast_image.d.ts to packages/image-tools

[hatem-72]

Overall, from what you say, I think you have a concern about sharing responsibility in your monorepo. If images-tools package is the only consumer for react-native-library, why do you need to make any reference to this library inside other packages ? Are you familiar with the adapter pattern ?

[samzmann]

@hatem-72 Thx for taking the time on this!

I'm not sure I understand:

If images-tools package is the only consumer for react-native-library, why do you need to make any reference to this library inside other packages ?

So just to clarify:

• packages/image-tools exposes various image components that rely on FastImage. image-tools must be used as part of an app in the apps/ directory. It lists RNFI as a peerDependency, not dependency or devDependency because of monorepo issues, but really should have RNFI as a devDependency.
• apps/App1 and other apps maybe must depend on RNFI if they use image-tools (to fullfil the peerDependency requirement), but may also depend on it for other uses unrelated to image-tools (eg. rendering webp images, etc.)

I've heard of the adapter pattern, but not particularly familiar with it. How might it help in this situation?

[hatem-72]

I am not sure to understand. Do you have example of import statements from RNFI you are using inside you app packages ?

I mean if your image component is using RNFI and this image component is exported from your image-tool package, your app packages should not even be aware of the existence of RNFI. At some point, if they use the same types used by the library, you should re-declare them with your own names inside the image-tool package.