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
Recent changes in TS 5.6 (ex. #58825) have meant that typescript more conditionally checks sourceFile.impliedNodeFormat. In Deno, we do all the resolution to tell if something is CJS or ESM and this property will always be set accordingly.
Would you be open to a PR that changes some of this code to instead ask the compiler host for the implied node format and the default implementation of that would use what's currently done in TypeScript? (I'm working around this issue in the meantime, but I'd rather not do so many custom changes just for this, which is why I'm opening this issue)
π Motivating Example
--
π» Use Cases
Deno where we know if a file is CJS or ESM already.
The text was updated successfully, but these errors were encountered:
I've been looking at the code more and I kind of feel like maybe I should be just using NodeNext in Deno. I guess it's on "Classic" at the moment even though it has its own custom module resolution.
π Search Terms
resolution mode compiler host
β Viability Checklist
β Suggestion
Recent changes in TS 5.6 (ex. #58825) have meant that typescript more conditionally checks
sourceFile.impliedNodeFormat
. In Deno, we do all the resolution to tell if something is CJS or ESM and this property will always be set accordingly.Would you be open to a PR that changes some of this code to instead ask the compiler host for the implied node format and the default implementation of that would use what's currently done in TypeScript? (I'm working around this issue in the meantime, but I'd rather not do so many custom changes just for this, which is why I'm opening this issue)
π Motivating Example
--
π» Use Cases
The text was updated successfully, but these errors were encountered: