Skip to content

Design Meeting Notes, 8/14/2020 #40052

Closed
Closed
@DanielRosenwasser

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions