Allow passing additional SupportedExtensions to support React Native .android and .ios module loading

[dfguo]

We are using TypeScript to write our React Native application and encountered an issue with platform specific extensions provided by RN.

React Native will detect when a file has a .ios. or .android. extension and load the right file for each platform when requiring them from other components.

For example, you can have these files in your project:

BigButton.ios.js
BigButton.android.js

With this setup, you can just require the files from a different component without paying attention to the platform in which the app will run.

import BigButton from './components/BigButton';

When we use tsc to compile our code, it won't recognize the android or ios platform extension. What about have a customPlatform option that's similar to allowJs that auto prepend the platform name to supportedTypeScriptExtensions?

function getSupportedExtensions(options) {
        if (options && options.customPlatform) {
          return ts.supportedTypeScriptExtensions.concat(ts.supportedTypeScriptExtensions.map((ext) => `.${options.customPlatform}${ext}`))
        }
        return options && options.allowJs ? allSupportedExtensions : ts.supportedTypeScriptExtensions;
    }

[zhengbli]

I think this problem might be better solved with the glob pattern support in tsconfig.json (#5980). Modifying getSupportedExtensions wouldn't scale.

[dfguo]

Makes sense. Love to see that change going in soon. Currently blocking our RN project.

[mhegazy]

Do not think globs will help here. the suggesion in the OP seems like a valid one. we should allow additional lookup locations, so that users can specify that, so "additionalExtensions" : [ "ios.ts", "ios.tsx", "android.ts", "android.tsx" ].

the workaround for now, would be create a .d.ts file next to your platform specific modules, something like:

/// components/BigButton.d.ts
export * from "./BigButton.ios"; 

this way your import for ./components/BigButton will resolve to ./components/BigButton.d.ts at design time getting you the shape of the module. and at runtime, it should do the right thing and bind to the platform specific version. there should not be any additional changes required.

[saulshanabrook]

@mhegazy If the exported types in BigButton.android.tsx diverges accidentally from BigButton.ios.tsx, then this won't be picked up at compile time, correct?

Is it possible to keep full compile time type checking?

[mhegazy]

The compiler does not know that BigButton.android.tsx and BigButton.ios.tsx are two implementation of the same module, and thus, should have the same shape. so they could diverge.

One possible solution here is to have modules implement interfaces, as previously suggested in #420. This will force the compiler to check the shape of the module against an interface.

[mhegazy]

here is another workaround to get it to type check today, courtesy of @RyanCavanaugh:

import * as ios from "./BigButton.ios"; 
import * as android from "./BigButton.ios"; 

declare var _test: typeof ios;
declare var _test: typeof android;

/// export to get the shape of the module
export * from "./BigButton.ios"; 

now if ios and android ever diverge, you will get an error on the redeclaration of _test. no code will be generated for this.

[mhegazy]

Recommendations here is to use path mapping support, see https://github.com/Microsoft/TypeScript-Handbook/blob/release-2.0/pages/Module%20Resolution.md#path-mapping

so your tsconfig.json should contain something like:

{
    "compilerOptions": {
        "paths": {
            "*": ["*", "*.ios", "*.android"]
        }
   }
}

this will tell the compiler when resolving an import to BigButton to look at:

• BigButton.tsx
• BigButton.ios.tsx
• BigButton.androdid.tsx

For checking that the different implementation for the modules all have the same shape is tracked by #420

[mhegazy]

closing in favor of #420