You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
orpaths
are set, which solves microsoft/TypeScript#26722:swc/crates/swc/src/config/mod.rs
Line 1388 in 7bea830
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):baseUrl
andresolveFully = false
currently. SoresolveFully = false
should point to this tier. But we also rewrite relative import extensions, which could be break changes.baseUrl
andresolveFully = true
currently. SoresolveFully = 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.
The text was updated successfully, but these errors were encountered: