Yup, looks good, thanks!

This will probably lead to breakage for some people, but unfortunately there’s not much we can do about that.

I'm not against this change, it is totally correct. But I can't understand why is this published as 0.56.10, this should not be published at all for now, because even RN 0.57 will not switch to fabric yet (

I think this should be published as 0.58.x when RN 0.58 will be released and only if it will use fabric after all.

@vovkasm This change brings the TS typings inline with the canonical Flow ones
facebook/react-native#19281 (comment). If we’d wait until the technical limitation is removed, it could mean other people start adopting this style now without realising they’ll have to remove it again soon.

Understand and this is valid position. But still think, that we could wait to follow versioning rules more strictly. But may be this rules only in my head? ))))
Anyway this change is very small and actually already done, so anyone can happily live with it. :-D

Only couple of notes:

1. typescript definitions still is much better that RN's own flow types.
2. there is other side of this concrete problem... it currently will not warn people against usage of props named as default style-props, but in current implementation of RN (<=0.56) this can lead to subtle bugs... because under the hood current RN still mix props and style-props, and do some preprocessing for some style-props.

But still think, that we could wait to follow versioning rules more strictly. But may be this rules only in my head?

There isn’t really any versioning rules that apply here afaict 😄 If we’re talking semantic versioning then things are allowed to break with any version < v1 and even if we wanted to do semantic versioning of just the typings then there’s no way currently to do that with DefinitelyTyped.

So yeah, not ideal but that’s what it is 🤷‍♂️

typescript definitions still is much better that RN's own flow types.

Really?? Wow, how can that be?

there is other side of this concrete problem... it currently will not warn people against usage of props named as default style-props

Can you expand on this? At Artsy we’re still on an older version so this doesn’t ring a bell for me.

typescript definitions still is much better that RN's own flow types.

Really?? Wow, how can that be?

Just one sample for resolveAssetSource but of course there are many in code:
flow: resolveAssetSource.js
d.ts:

Can you expand on this? At Artsy we’re still on an older version so this doesn’t ring a bell for me.

I can create native extension (subclass of RCTView) for ex RNBadView. And create property transform, so my view can be used like this:

<BadView transform="myDarkSuperEffect"><View>...</View></BadView>

Definition would be:

import React from 'react'
import { ViewProps } from 'react-native'

export interface BadViewProps extends ViewProps {
  transform: 'myDarkSuperEffect' | 'myLightSuperEffect'
}

export declare class BadView extends React.Component<BadViewProps> {
  render(): React.ReactNode
}

This will be passed by typescript without any problems now, but before it was error because transform was already in ViewProps. And it will run without any problems (Before experiment on RN 0.56 I thought, that this will be corrupted value on native side or js error in validation of transform style prop, but no... actually style props validation occurred before mix of props and style props). This will not work however:

<BadView transform="myDarkSuperEffect" style={{ transform: [{ scale: 0.5 }] }}>...</BadView>

Style prop will be ignored (it relatively hard and need more time to find code that controls this behaviour, so I can't be sure about priority for now... may be it always stable, may be in some cases style prop will have priority).

In any case before this pull request programmers was warned about props vs style props conflicts. Now they will not...

Again, I don't really think that this should be motivation to revert anything... But for future changes it would be good to specify versioning scheme for typings explicitly... Yes we can't use semantic versioning here... but we can use half-part of it... we can stand for ex: "Major and Minor version of typings directly link to specific RN version. But patch version - is our feature + bugfix number" This will work, because we known that RN uses patch version number only for bugfix changes.

Hmm, I see, thanks for the detailed explanation 🙏 At least now it will be documented in a logical place for people to find.

Regarding the future, I’m not sure I fully understand still. We don’t really control the versions of these DT packages. We can only specify what major+minor version of the package the types apply to. The patch segment of the version is in control of DT and is auto-increased for each merged DT PR. Are you saying, as previously, that we delay making changes like these until a minor version of RN gets released?

before this pull request programmers was warned about props vs style props conflicts. Now they will not

If that turns out to be an issue after fabric, we can make these fields as never

Are you saying, as previously, that we delay making changes like these until a minor version of RN gets released?

Yes, it would be better in my opinion, but of course it needs more wide consensus )
I think also... Does something prevents us from publishing forward version of typings for upcoming RN release? Can we release change that sure will be in RN 0.57 as @types/react-native-0.57.0 before even RN 0.57 will be released itself?

@brunolemos If we do this, poor react-native-linear-gradient will be broken again :D