GeezerVison

The TypeScript team hasn't accepted the linked issue #21926. If you can get it accepted, this PR will have a better chance of being reviewed.

Oops, some of my suggestions are redundant with Sheetal Nandi (@sheetalkamat)’s; her review came in while I was still browsing 😄

Thanks Adam Foxman (@afoxman)!

I think this option is very useful, but thinking about it, I have two questions:
There is a way as a consumer to know what bundle I need to consume?

The other stuff is: There may be cases where a module's interface changes depending on the compiled platform, such as IDEs or text editors identifying the types to use

Hi Julio Rodriguez (@jircdev), I think your questions fall into the realm of React Native, so I'll answer in that context.

I think this option is very useful, but thinking about it, I have two questions: There is a way as a consumer to know what bundle I need to consume?

It's up to the package producer to establish any rules about which artifacts apply to which platform.

The other stuff is: There may be cases where a module's interface changes depending on the compiled platform, such as IDEs or text editors identifying the types to use

Yes, this is a problem that has yet to be solved. IDEs like VS Code would benefit from having a platform selector which influences how modules (and therefore types) are resolved for browsing. This is a big undertaking, and will require a VS Code plugin and some changes to the TypeScript Server. I don't think it's APIs have enough flexibility to support this scenario.

Hi Adam Foxman (@afoxman),

I believe I was not clear enough before with the first point, let me clarify it;

Hi Julio Rodriguez (@jircdev), I think your questions fall into the realm of React Native, so I'll answer in that context.

I think this option is very useful, but thinking about it, I have two questions: There is a way as a consumer to know what bundle I need to consume?

It's up to the package producer to establish any rules about which artifacts apply to which platform.

I know it not depends on Typescript or React Native but I want to know your opinion.

If I am the creator of a package which I end up building for two platforms (ios and android), How can the dev tools that need to consume this package identify which file must be considered and included? or How can Typescript which is the declaration type to take as valid?

In the NodeJS documentation, they talk about conditional exports and the possibility of adding multiple "target platforms", such as Node, Browser, or Deno but they do include ios or android (that is a requirement beyond of React Native). I think we may use this entry point (conditional exports) to solve the problem in a standardized way and take advantage of it to specify that kind of requirement.

What is your opinion?

If I am the creator of a package which I end up building for two platforms (ios and android), How can the dev tools that need to consume this package identify which file must be considered and included? or How can Typescript which is the declaration type to take as valid?

In the NodeJS documentation, they talk about conditional exports and the possibility of adding multiple "target platforms", such as Node, Browser, or Deno but they do include ios or android (that is a requirement beyond of React Native). I think we may use this entry point (conditional exports) to solve the problem in a standardized way and take advantage of it to specify that kind of requirement.

What is your opinion?

Node's conditional exports talk about "environment", not "platform", and the examples of default, production, and development suggest this needs to stay separate from the concept of a platform.

I deliberately avoided codifying a standard or even a suggestion about how a React Native package would export both ios and android built artifacts (e.g. transformed TS/Flow files, assets, etc). Getting to a decision there requires broad consensus, and probably a set of working/proven packages that are successfully demonstrating it.

If I had to guess at how it might work, I think the answer starts in react-native.config.js. This is specific to React Native, which makes it appropriately scoped. And there is room in there for platform-specific information. The config schema is defined as part of the React Native CLI. But there is nothing in config today which attempts to define "build artifacts" for a platform+package. So you'd be breaking new ground.