Question: how would `tsc --moduleFormatDetection` affect tshy?

[andrewbranch]

I’m starting to dive into prototyping some stuff for https://github.com/microsoft/TypeScript/issues/55221. If TypeScript had support for these options, would tshy leverage any of them? Would you have written tshy if they had already existed?

• the ability to determine module format by reading package.jsons starting from the outDir path, not the input file path
• the ability to determine module format by assuming all .ts/.js/.d.ts are ESM
• the ability to determine module format by assuming all .ts/.js/.d.ts are CJS

Is there a different module format detection algorithm along these lines that would be useful for building libraries with or without tshy?

[isaacs]

• Reading from the outDir path does make more sense, I think, whether using tshy or not, since that's where it actually matters. In most cases, presumably they're the same thing (the nearest package.json to both ./src and ./dist will typically be ./package.json), but it is more technically correct in every case I can think of, and would simplify tshy's job considerably.
• Ability to assume that all .ts/.js/.d.ts are ESM or CJS would be helpful for tshy. This is actually how tshy's predecessors worked, where I'd do "module":"commonjs" or "module": "esnext" with "moduleResolution": "NodeNext". But it would have to be limited to a given source directory. Eg, I wouldn't want ./node_modules/foo/index.d.ts to be interpreted as ESM/CJS just because I'm interpreting ./src in some overridden way. If it was determined by the outDir, though, I wouldn't have to do that, I'd just have to write the dist package.json before calling tsc.