Repository navigation
generated output don't follow moduleSuffixes option #49586
Description
Bug Report
typescript generated output don't follow moduleSuffixes option,
🔎 Search Terms
searched terms: moduleSuffixes, result none
🕗 Version & Regression Information
typescript@4.7.3 and typescript@next(4.8.0-dev.20220616)
💻 Code
create 2 ts files
a.web.ts
export const a = "web"a.node.ts
export const a = "node"create index.ts
import {a} from './a'create tsconfig.json with
{
"moduleSuffixes":[".node",""]
}run tsc -w
🙁 Actual behavior
generated index.js directly imports a from './a'
🙂 Expected behavior
generated index.js directly imports a from './a.node' according to moduleSuffixes
Activity
Josh-Cena commentedon Jun 17, 2022
Nothing in TS re-writes import paths. They only inform TS about existing path mappings.
MartinJohns commentedon Jun 17, 2022
What makes you think that's the purpose of
moduleSuffixes? I couldn't find any documentation regarding this flag. Related: microsoft/TypeScript-Website#2423ryanroe commentedon Jun 17, 2022
i read that from blog here , so i naively think that that's the purpose
DanielRosenwasser commentedon Jun 17, 2022
Sorry it wasn't more explicit - we won't do path rewriting.
moduleSuffixesis meant to inform TypeScript of how your runtime/resolver will resolve the paths.So if you have a bundler or resolver plugin that will try to look up
.node-suffixed name,moduleSuffixeswill allow TypeScript to understand that - but TypeScript will defer to that bundler/resolver to do that later and not touch the paths. React Native's Metro is the most well-known example of a bundler with a resolution strategy like this.typescript-bot commentedon Jun 20, 2022
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
cccRaim commentedon Jul 28, 2022
Daniel Rosenwasser (@DanielRosenwasser)
I got the same issue, it's working as intended or not, maybe should ask Adam Foxman (@afoxman) .
#48189
The original intend is above.
So if
moduleSuffixesis[".node",""], ts should use*.node.tsfirst instead use*.ts, unless there is no*.node.tsfile.But now ts use
*.tsfirst, I think it's not work as intended.DanielRosenwasser commentedon Jul 28, 2022
It will resolve that way, but we won't rewrite the paths when we output JavaScript code. We expect that a loader of some sort will prefer
foo.node.jsoverfoo.js.If something isn't working for you, I'd guess it's probably because Node.js doesn't do that by default. You'll need to find some sort of loader hook for it.
afoxman commentedon Jul 28, 2022
Sorry this isn't clear.
moduleSuffixesdoes appear to be working correctly. As Daniel Rosenwasser (@DanielRosenwasser) said, the intent is to teach TypeScript how modules are resolved by apps like Webpack/Metro. Not to change emitted code.This lets TypeScript build a matching file graph and run type-checking on it. For example, when building a React Native Android app, Metro will only bundle .android.ts files, it won't bundle .ios.ts files. So .ios.ts files should not be considered when type-checking Android builds.
cccRaim commentedon Jul 29, 2022
Adam Foxman (@afoxman) Daniel Rosenwasser (@DanielRosenwasser)
😂My fault, I misunderstood what the issue publisher meant.
Rewrite is wrong.
But I do have the wrong logic of module load though. Maybe I should publish a new issue.
Thx reply.
KlasikNormalBoy commentedon Sep 5, 2022
I feel that documentation on https://www.typescriptlang.org/tsconfig#compilerOptions is very poor for paths and suffixes if this is the behaviour. It should clearly state that this will not change the output of TSC
KlasikNormalBoy commentedon Sep 5, 2022
I found that here: https://www.typescriptlang.org/docs/handbook/module-resolution.html#additional-module-resolution-flags.
But this should be much more prominent on the tsconfig page, since this is the first entry point in looking for these options.