Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

• feat(isolated-declarations): infer undefined as any type #3798 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Dunqing and the rest of your teammates on Graphite

CodSpeed Performance Report

Merging #3798 will not alter performance

_{Comparing 06-21-feat_isolated-declarations_infer_undefined_as_any_type (ccb7b52) with main (f8fe583)}

Summary

✅ 28 untouched benchmarks

I'm like 99% certain this is a bug in transpileDeclaration. See below; this is due to strictNullChecks.

I'm like 99% certain this is a bug in transpileDeclaration.

Thank you for noticing us.

We are conforming against https://github.com/microsoft/TypeScript/tree/main/tests/cases/transpile so we will just port bugs if they occur (because we don't really understand the underlying logic).

We will correct this once upstream is fixed.

Ah, you're testing this with strict off; undefined doesn't "exist" without strictNullChecks, hence what you're seeing here. With this test on TS:

// @declaration: true
// @target: es6
// @strict: true

const a = undefined;
using d = undefined;
function c(p = undefined): void {}

//// [declarationUndefined.ts] ////
const a = undefined;
using d = undefined;
function c(p = undefined): void {}
//// [declarationUndefined.d.ts] ////
declare const a: undefined;
declare const d: undefined;
declare function c(p?: undefined): void;

I would likely be copying the code over as-is; not sure why we don't, so that's its own problem. transpileDeclaration is not currently restricted from using the checker in specific places, something being worked on. (That or this is "intentional" because undefined is trivially understandable without strict to not actually mean anything, sorta like a never except if it exists on its own, it's any...)

@Dunqing Let's gather a few cases where the playground and the transpileDeclaration API differ. I think it's mostly when errors occur, one or the other will reach to the type checker to get the types, but our implementation don't have type inference obviously.

Ah, you're testing this with strict off; undefined doesn't "exist" without strictNullChecks, hence what you're seeing here. With this test on TS:

The API document doesn't mention strictNullChecks: false. Is this a bug or just forget to add it?
https://github.com/Dunqing/TypeScript/blob/d8086f14b6b97c0df34a0cc2f56d4b5926a0c299/src/services/transpile.ts#L68-L82

That comment only shows the compiler options which differ from the defaults ("If no options are provided - it will use a set of default compiler options.").

strictNullChecks is disabled by default (unfortunately). You should pull compiler options from the resolved tsconfig that would be used to compile the code normally via tsc/tsserver/etc.

That comment only shows the compiler options which differ from the defaults ("If no options are provided - it will use a set of default compiler options.").

strictNullChecks is disabled by default (unfortunately). You should pull compiler options from the resolved tsconfig that would be used to compile the code normally via tsc/tsserver/etc.

Thank you for explaining this. Unfortunately, we're not going to read tsconfig.json yet.

I think for now we just need to be consistent with the default configuration of transpileDeclaration

I think you'd be better off assuming strict=true, if anything.

If you write "undefined" to the output, then non-strict consumers will still get it right. Definitely don't write out any...

I think you'd be better off assuming strict=true, if anything.

If you write "undefined" to the output, then non-strict consumers will still get it right. Definitely don't write out any...

Ok, I agree. FYL: The strict in tsconfig.json created by tsc --init is set to true.