Add a new compiler option moduleSuffixes to expand the node module resolver's search algorithm

[afoxman]

This PR expands the node module resolver's search algorithm to include a list of module suffixes:

// react-native use-case: import './foo' -> search for foo.ios.ts, then foo.native.ts, and finally foo.ts
{
    "compilerOptions": {
        // empty string --> match without an extension
        "moduleSuffixes": [".ios", ".native", ""]
    }
}

// alternative use-case: import 'foo' -> search for foo-primary.ts, then foo__alt.ts (stop there)
{
    "compilerOptions": {
        "moduleSuffixes": ["-primary", "__alt"]
    }
}

This impacts all TypeScript workflows, including build and parsing for IntelliSense.

Developers who take advantage of this would have one tsconfig file per moduleSuffix list. The config file name should not be constrained to any particular pattern. Many 3rd-party tools already support specifying a tsconfig file name, explicitly, which makes this approach a good choice.

IntelliSense will need additional support to make this work. With multiple tsconfigs in play, IntelliSense will need to be told which one to use, or it will default to loading tsconfig.json. For the react-native use-case, I'm imagining this will be an IDE extension that exposes a platform selector in its config and/or in the UI. The corresponding tsconfig for that platform is passed to the IntelliSense tsserver process.

Fixes #21926

[typescript-bot]

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.

[andrewbranch]

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

[sheetalkamat]

i think instead of this we should just check if option is defined and get rid of listPreserveFalsyValues

[afoxman]

That would change the behavior of other lists, like types, which could impact existing projects. Why risk exposing them?

To be clear what you're looking for, the filter condition would become v => v !== undefined?

[afoxman]

@sheetalkamat Would you like to make this change, or is the risk of impacting existing projects too great? Please advise.

[andrewbranch]

Thanks @afoxman!

[jircdev]

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

[afoxman]

Hi @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.

[jircdev]

Hi @afoxman,

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

Hi @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?

[afoxman]

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.