Design Meeting Notes, 8/14/2020

[DanielRosenwasser]

paths without baseUrl

#31869

• One of the things you have to do every single time you set up paths is set baseUrl.

• baseUrl makes sense with the browser behavior in mind.

• So why do you need both?

  • Require.js legacy reasons.
  • Unclear, niche scenarios when you use both otherwise?

• Proposal: whenever there's no baseUrl, resolve each path relative to the tsconfig.json.

• What about non-relative mappings?

  {
      "compilerOptions": {
          "paths": {
              "foo": ["react"],
              "components": ["./shared/components"],
              "components/*": ["./shared/components/*"],
          }
      }
  }

  • Also, what about circularities?

    {
        "compilerOptions": {
            "paths": {
                "foo": ["yadda"],
                "yadda": ["foo"],
            }
        }
    }

• Could always say when there's no baseUrl, all paths must be relative.

• Could also use rootDir instead of tsconfig.json location.

  • rootDir is poorly understood, doesn't do what most people think, don't use it.

• Conclusion: put put a PR, try it out.

Treat Trailing undefined/any/unknown Parameters as Optional

#39817

• Usually, a promise's resolver callback requires a parameter.

  new Promise<number>(resolve => {
      resolve(); // Error - required 1 parameter of type `number`.
  });

• We have some special-cased behavior for void - if you have void, then the parameter is considered optional.

  new Promise<void>(resolve => {
      resolve(); // Parameter is optional because it's `void`.
  });

• Idea: if you have trailing undefined or any or unknown parameters, then these become optional.

• Problem: this weakens the TypeScript side.

  • Considering only doing this for TypeScript.

• People definitely don't want strict.

• Does --strict with JavaScript make sense? Is it coherent!

  • Yes! ish

• So only outside of strictNullChecks?

  • Sure!
  • *tries it out*
  • uh oh, number | undefined becomes number outside of strictNullChecks 😬

• Conclusion: try without strictNullChecks, check with @sandersn.

Update on Recursive Conditional Types

#40002

• OOM issues due to the switch to use isDeeplyNestedType for recursion tracking.
• Pathological examples where we do enormous amounts of work.
• If you're inferring from 2 type references, and you come back to the same type references, you often don't get helpful inferences.
• The reason we do "up to 5 levels of exploration" in inference is that we do get a little further with type references when inferring from Box2<Box2<string>> to Box1<Box1<T>>.
• Newest commits just track just 1 level of recursion. As soon as we see 2 types with identical "recursion identities" (new concept that relates potentially-recursive constructs back to their origin location), we stop.
• Have some fix-ups for literal types - object literals aren't recursive.
  • Sure they are!
    • What about a getter with this?
      • Oh no