René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design Meeting Notes, 3/26/2024","articleBody":"# Format Types Consistently in Baselines and Underlining Type Node Generation\r\n\r\n* https://github.com/microsoft/TypeScript/pull/57890\r\n* https://github.com/weswigham/TypeScript/pull/69\r\n\r\n* As we try to maximize node reuse, we realized we have no indication as to whether that is taking place apart from whitespace as a heuristic.\r\n* Even then, preserving whitespace isn't always desirable.\r\n* This PR adjusts type baselines to always apply the same formatting consistently.\r\n* A separate PR adds an underline to indicate when a node was synthesized.\r\n* What are we trying to catch here?\r\n    * Lack of node reuse.\r\n    * Could exhaustively check things, but better off using our current infrastructure.\r\n* Kind of a pain to read these.\r\n* Is it arguable that the underlines actually indicate that you *should* pay attention even if you only care about the types?\r\n    * Maybe.\r\n* Aside: do we need symbol baselines?\r\n\r\n# `tsc --noCheck`\r\n\r\nhttps://github.com/microsoft/TypeScript/pull/57934\r\n\r\n* For TypeScript? Isn't that *weird*??\r\n* Idea: allows people to perform a check and a build separately.\r\n* Declaration emit actually *surprisingly* works here. Most of the information can be calculated lazily, and so it avoids a *full* check.\r\n* Unfortunately, JavaScript emit actually calculates some information in the checker.\r\n* This is *very surprisingly fast*.\r\n* The only downside of using `--noCheck` for declaration emit is that it may differ in output from stuff like union ordering (which depends on types being assigned IDs, which is sensitive to check order).\r\n* Our main goal is to be a type-checker.\r\n* How does this work with syntax errors?\r\n    * You *won't* get them.\r\n* Unclear if it's a good idea to bring this in without making this possible for the JS side. We need to try decoupling JS emit to see what if anything regresses.\r\n* Mixture of support for the concept of `--noCheck`, but if we can unlock this for `transpileModule` that would be a big win.\r\n* Don't want to add a command line flag just yet.\r\n* Bike-shed a name.\r\n    * `skipCheck`?\r\n    * `noCheck` to parallel `noEmit`?\r\n\r\n# Respect `type` in `package.json` in more `module` modes\r\n\r\nhttps://github.com/microsoft/TypeScript/pull/57896\r\n\r\n* Some notable changes:\r\n    * A `.cjs` module under `--module esnext` got emitted with ES syntax; no longer does.\r\n    * People using `.cts` files under `--moduleResolution bundler --module esnext` (aside: nowadays `--module preserve` is what most of these people want), we would resolve with the `import` condition, now resolves with the `require` condition.\r\n        * Kind of weird under `--preserve`, but 🤷‍♂️.\r\n    * Under `--module preserve`, we issue something like `verbatimModuleSyntax` errors because it won't be interpreted the same way from a declaration file.\r\n* Did *not* add logic to disallow CommonJS input files. Presumably a program-level error if we wanted to add it.\r\n","author":{"url":"https://github.com/DanielRosenwasser","@type":"Person","name":"DanielRosenwasser"},"datePublished":"2024-03-28T03:29:15.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/57980/TypeScript/issues/57980"}