Skip to content

[RFC] Progressively rewrite import specifiers #10130

@CPunisher

Description

@CPunisher

Motivation

TSC insists on not rewriting import specifiers to keep the semantics of JavaScript (See: microsoft/TypeScript#26722 (comment), microsoft/TypeScript#16577 (comment)), although there is an exception of --rewriteRelativeImportExtensions (microsoft/TypeScript#59767)

However, SWC resolves and rewrites the import specifiers to actual relative paths when baseUrl or paths are set, which solves microsoft/TypeScript#26722:

let skip_resolver = base_url.as_os_str().is_empty() && paths.is_empty();

Even with resolveFully, swc add an index file path component when resolving a directory, See #7945 (which solves microsoft/TypeScript#16577).

I don't think swc does something wrong because these are all popular requested demands. But I think it's better to provide a way to make it possible to align the behaviors between tsc and swc, without introducing break changes as much as possible. Also, I hope this way will be compatible with potential future changes in tsc.

Different levels to control how to rewrite import specifiers

Currently, I come up with an idea of setting different levels to rewrite import specifiers progressively. We can reuse resovleFully (or deprecate it and create a new one):

  • Tier 0: Keep consistent with tsc and NO rewriting relative import extensions.
  • Tier 1: Keep consistent with tsc and rewrite relative import extensions.
  • Tier 2: Equivalent to setting baseUrl and resolveFully = false currently. So resolveFully = false should point to this tier. But we also rewrite relative import extensions, which could be break changes.
  • Tier 3: Equivalent to setting baseUrl and resolveFully = true currently. So resolveFully = true should point to this tier.

Actually one question is how to merge --rewriteRelativeImportExtensions and potential features in the future to current rewrting rules.

Another option is to create separate consistent flags in swc, then consider different flag combinations and their interops. For example, by detaching tier 1 to an isolated rewriteRelativeImportExtensions option, we don't map and rewrite the file extension in tier 2 and tier 3 if it's false.

Addition Context

I'm considering this rfc when I'm thinking how to implement the request of rewriteRelativeImportExtensions in #9611.

Please correct me if I'm missing something.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions