Feature request: customize removal of extension on es6 imports to better support TypeScript/deno environments

[chrisirhc]

Looks like gentype only supports .bs.js extension but then proceeds to remove the .js in the import statements.
Examples missing extension:
https://github.com/rescript-lang/rescript-compiler/blob/457aeff9948c40fee5fc47df6e431152bd65d869/jscomp/gentype_tests/typescript-react-example/src/JSXV4.gen.tsx#L5

This behavior relies on non-standard import behavior. According to MDN ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#module-name ) ,

The module to import from. The evaluation of the specifier is host-specified. This is often a relative or absolute URL to the .js file containing the module. In Node, extension-less imports often refer to packages in node_modules. Certain bundlers may permit importing files without extensions; check your environment. Only single quoted and double quoted Strings are allowed.

If the .js isn't removed, the TS code and JS code could be compatible with Deno and potentially other bundlers/environments.

Looks like this behavior is also present in the main compiler and on every .bs.js file. Wonder if the community would consider this change interesting/useful to open up to more environments perhaps like Deno or Bun etc.

Related to #4965 #5530

[cristianoc]

This is what happens if you add the extension:

import {make as makeNotChecked} from './hookExample.tsx';

then run tsc:

% npx tsc
src/JSXV4.gen.tsx:5:38 - error TS2691: An import path cannot end with a '.tsx' extension. Consider importing './hookExample' instead.

5 import {make as makeNotChecked} from './hookExample.tsx';
                                       ~~~~~~~~~~~~~~~~~~~


Found 1 error.

[chrisirhc]

Looks like this extension enforcement was a constraint in TypeScript but no longer as of a month ago:
microsoft/TypeScript#27481 (comment)

[cristianoc]

We can't assume people have the latest TS, and have configured it in that specific way.

[chrisirhc]

You’re right, we can’t. But we can assume that deno users are using that configuration. The current configuration breaks deno usage completely. I’m not asking for a new default, but that this behavior be configurable.

[cristianoc]

I'd like to learn more about that.
Perhaps the example mentioned is not the intended one. Notice this can be used in the source file:

@genType.import("./hookExample.tsx")
@react.component
external make: (
...

and produces an import to `.tsx.

I guess you're referring to other examples.
It might be useful to start with a couple of small self-contained examples that illustrate the issue.

[cometkim]

Adding a module resolution mode may be reasonable. TypeScript requires different extensions depending on the tsconfig.json

https://www.typescriptlang.org/tsconfig#moduleResolution

• { "moduleResolution": "Node" }: It's for Node's node_modules resolution (basically require.resolve). When importing a local module from a relative path, there must be no extension.
• { "moduleResolution": "Node16" } or { "moduleResolution": "NodeNext" }: For compatibilities with ESM. When importing a local module from a relative path, there must be a extension in .js (or .cjs/.mjs), not .ts
• { "moduleResolution": "Bundler" }: From TypeScript v5, it allows extensions of all formats commonly supported by bundler. (including no extensions). This also available for Deno or Bun which use bundler internally.

[cristianoc]

What's a concrete proposal for module resolution mode? How would the setting look like and what would the effect be?

[cometkim]

What's a concrete proposal for module resolution mode? How would the setting look like and what would the effect be?

Usually the setting is only needed in gentypeconfig and modifies the way to import statments are printed.

Some given code like:

@genType
let makeOther: () => Other.t = { ... }

would generate like this:

import * as Module_BS__Es6Import from './Module.bs';

import type {t as Other_t} from './Other.gen';

Assuming this follows the default settings:

{
  "gentypeconfig": {
    "moduleResolution": "node" // default, identical to current behavior and TypeScript's default.
  }
}

(Option names intentionally follows the naming convention of tsconfig.json's)

In a TypeScript project with the same setup, this works well.

If user changes the setting to:

{
  "gentypeconfig": {
    "moduleResolution": "node16"
  }
}

should generates:

import * as Module_BS__Es6Import from './Module.bs.js'; // extension required for ESM compatibility

import type {t as Other_t} from './Other.gen.js'; // extension here should follows the TS output's

and

{
  "gentypeconfig": {
    "moduleResolution": "bundler"
  }
}

should generates:

import * as Module_BS__Es6Import from './Module.bs.js';

import type {t as Other_t} from './Other.gen.ts'; // TS extension for most bundlers, Deno, Bun, etc

[cristianoc]

Does one of these names "bundler" etc indicate a specific extension? Is it better to specify by name or by extension?

[cristianoc]

In general, this should be pretty easy to add.

[cristianoc]

PRs accepted. This could be a good opportunity to check that the genType code is easy to modify. And if not, clean up parts of it in the process based on feedback. Generally, it should be quite approachable.

[cometkim]

Does one of these names "bundler" etc indicate a specific extension? Is it better to specify by name or by extension?

IMO it's easy to understand when matched with the tsconfig. Since It is intended for interoperability with the TypeScript projects.

Emitting with full extension is enough for JS/Flow. And user can customize it's own resolution for Flow by the flowconfig anyway.