Design Meeting Notes, 2/23/2024

[DanielRosenwasser]

Exposing Internal Performance Tracing APIs

#57477

• Add tracing to API?
• Probably would like to rename it.
• No objections per se, but was thinking about using Disposables - so we might want to make some API changes.
• For now our advice is to reach into our internals with a cast/type assertion, and in the meantime we'll update the API appropriately.

Customizing Behavior of tsconfig Extending (merging/overriding)

#57486

• Have a table of all the options that are lists or objects.

• include/exclude?

  • Probably want to override them?
  • Or you want to just inherit them?
    • You do?
  • Depends on inter-project vs intra-project inheritance.

• Reconsidering if "merge all fields" makes sense.

• How does it work when an intermediate config says "don't merge" and the root says "do merge" or vice versa?

  • Each step of the process produces a complete tsconfig.json.

• Multiple inheritance?

  • Okay, here we go.

    // a/tsconfig.json
    {
        "includes": [
            "src"
        ]
    }
    
    // b/tsconfig.json
    {
        "includes": [
            "cool-src"
        ]
    }
    
    // TMP-TSCONFIG.json
    // Today this is how this works disregarding merging.
    // But it is arguable if this is desirable when merging!
    {
        "includes": [
            "cool-src"
        ]
    }
    
    // c/tsconfig.json
    {
        "extends": ["../a/tsconfig.json", "../b/tsconfig.json"],
        "mergeFields": [
            "include",
        ]
    }
    
    // what is the effective c/tsconfig.json?
    
    {
        "include": [
            "cool-src",
        ]
    }
    
    // vs.
    
    {
        "include": [
            "src",
            "cool-src",
        ]
    }
    
    // arguable
    
    // could be an object to specify exactly what you want
    // c/tsconfig.json
    {
        "extends": [
            { "path": "../a/tsconfig.json", "strategy": "merge" }
        ],
        "mergeFields": [
            "include",
        ]
        "compilerOptions": {
        }
    }
    
    // omg don't drown us in complexity

• How do we design this?

  • mergeFields: [option name array]?

• DO MERGE LISTS MERGE?

  • "Ahhhhh!!"
  • No?
  • But it feels weird that you have to specify at every step along the way.
    • But then any downstream tsconfig.json is susceptible to accidentally merging data from its bases.
    • You should be able to eyeball a tsconfig.json and
  • You also want to view the effective tsconfig.json as flattened

• Templating variables?

  {
      "extends": [
          { "name": "a", "path": "../a" },
          { "name": "b", "path": "../b" },
      ],
      "compilerOptions": {
          "target": "${a:target}"
      },
      "include": [
          "${a:include}", 
          "./**/*",
          "${b:include}"
      ]
  }

  • How would you specify the paths of a or b?
    • These are not strings, paths is an object with entries.

• It sounds like the feedback we've gotten from developers is they want the shortest possible tsconfig.json.

  • Is that really the problem? Or is it manually rewriting stuff that can fall out of date.

[rubiesonthesky]

I think this bullet point is missing some words after and.

You should be able to eyeball a tsconfig.json and

[saltman424]

Highlighting some answers from #57486 (comment) to the above questions

---

• Templating variables?

  {
      "extends": [
          { "name": "a", "path": "../a" },
          { "name": "b", "path": "../b" },
      ],
      "compilerOptions": {
          "target": "${a:target}"
      },
      "include": [
          "${a:include}", 
          "./**/*",
          "${b:include}"
      ]
  }

Yes, please! But I don't think the :target or :include is necessary. And it would be nice to have ${*} to reference all extended tsconfigs in the order that they are specified in extends, for cases where you don't need to mess with the order. E.g.

{
    "extends": [
       { "name": "a", "path": "../a" },
       { "name": "b", "path": "../b" },
    ],
    "compilerOptions": {
        "target": "${a}"
    },
    "include": [
        "${*}", 
        "./**/*",
    ]
}

---

• How would you specify the paths of a or b?

  • These are not strings, paths is an object with entries.

A few options:

1. paths supports lists for merging

"paths": [
  "${a}",
  "${b}",
  {
    "@mystuff/*": [ "./*" ]
  }
]

2. paths uses a special symbol for merging (e.g. &)

"paths": {
  "&": [ "${a}", "${b}" ],
  "@mystuff/*": [ "./*" ]
}

3. This might be complicated, but you could use matching to determine which paths are extended

"paths": {
  "*": [ "${a}" ],
  "@b/supported/*": ["${b}"],
  "@mystuff/*": [ "./*" ]
}

In this case, all the paths from a are usable, but only the paths from b that match @b/supported/* are usable.

---

• It sounds like the feedback we've gotten from developers is they want the shortest possible tsconfig.json.

  • Is that really the problem? Or is it manually rewriting stuff that can fall out of date.

Short is nice, but manually rewriting is a much bigger concern.