Compatibility with other extensions to react-native such as react-native-web

[nickdima]

I was wondering how this approach of extending the react-native type definitions would scale to accomodate also other stuff. For eg. over at the react-native-web repo there's an ongoing similar discussion: https://github.com/necolas/react-native-web/issues/832 Maybe an idea would be to have an "umbrella" repo that covers all this extensions pulling them from various repos. I don't have a lot of experience with TypeScript myself...

[nickdima]

It looks like you can augment the react-native typings like this:

import * as reactNative from "react-native";

declare module "react-native" {
  interface ViewProperties {
    className?: string;
  }
}

Trying it in a local file in my project it works. It should probably work as a node module as well.

[kristerkari]

Thanks @nickdima!

I was wondering how this approach of extending the react-native type definitions would scale to accomodate also other stuff.

I don't know if my approach is a very optimal one, it's just something that I could get to work easily. I'm open for suggestions on how to improve things.

It looks like you can augment the react-native typings like this:

That looks good! I've been wondering if there is a clean way to extend existing types.

Two things came to my mind:

• Would that mean that we still need to use the package.json linking: "@types/react-native": "kristerkari/react-native-types-for-css-modules"?
• Extending the types from @types/react-native would mean that they might get out of sync easily if style properties get added or removed, or if a name of an interface gets changed. So there would still need to be a script that keeps things in sync with @types/react-native.

[nickdima]

Would that mean that we still need to use the package.json linking: "@types/react-native": "kristerkari/react-native-types-for-css-modules"?

Yes, I think the best way would be to add it as a peer dependency.

Extending the types from @types/react-native would mean that they might get out of sync easily if style properties get added or removed, or if a name of an interface gets changed. So there would still need to be a script that keeps things in sync with @types/react-native.

The peer dependency on @types/react-native should take care of that, right? Just make the needed changes, bump the version and also update the peer dependency version.

[kristerkari]

The peer dependency on @types/react-native should take care of that, right? Just make the needed changes, bump the version and also update the peer dependency version.

That's not what I meant :) I'll try to explain it better:

So, we might add something like this to our type defs:

  interface ViewProperties {
    className?: string;
  }

Now, if someone goes and renames ViewProperties to ViewPropertiesAndSomething in @types/react-native, then our type definitions will not be compatible any more.

Same thing will happen if they add interface CoolViewProperties that has a style property. We will need to update our type definitions. And same thing if they decide to remove style property from some interface.

React Native's type definitions are updated so often that it will be very hard to keep them in sync without automated updates and that's why I created a script to do that.

[nickdima]

Yeah, but if they make changes to the type defs they will bump the version so when a user updates the package NPM or yarn will complain about the new version not being compatible with the peer dependency declared in the other package.

Not sure I understood how your script works. The user has to run it?

[kristerkari]

Not sure I understood how your script works. The user has to run it?

Nope, the user does not run the script. It is something that I usually run every day.

The script looks for newer @types/react-native versions from npm, installs new versions locally, adds className property to any interface that has style defined, and then tags a new Git tag with that version.

This way the versions that the script creates are always exactly the same as the @types/react-native version, with only the className property added.

when a user updates the package NPM or yarn will complain about the new version not being compatible with the peer dependency declared in the other package.

Using a peer dependency that gets bumped is a good solution, but there should still be a script to do it to easily discover any updated type definitions.

The script would install newer @types/react-native versions, and if there are any changes that require updates, it would make the changes, tag a new version, and then bump the @types/react-native peer dependency version.

[kristerkari]

Just to clarify:

I think that extending the types of @types/react-native is a good idea, but it needs to be done in a way that

• it's easy for the user to update (currently I have git tags that match the npm versions of @types/react-native)
• can be easily kept up-to-date with the source types (currently there the script makes sure that this repo and @types/react-native don't get out of sync).

[nickdima]

Yeah, sure, the script is a good idea.