Design Meeting Notes, 6/15/2022

More-Specific TemplateStringsArray

https://github.com/microsoft/TypeScript/pull/49552

• We have a sort of gap in what you can express between function calls and tagged templates.
• Some things that are lacking
  • Being able to infer specific values and raw values in place of a more-broad TemplateStringsArray type.
  • Inference in the face of intersections.
• Why? Why now?
  • Has come up in a few issues.
  • Relatively little work.
  • Wanted to power more powerful mechanisms using plug-ins in tsc, but the type-system might be powerful enough now.
  • It’s an asymmetry with function calls.
• We said don’t do this (https://github.com/microsoft/TypeScript/issues/45504). The type system isn’t optimized to be a parser. Function calls maybe provide enough “syntactic salt”. So why do we want to incentivize this?
  • You can already do this today.
  • Also, language service plugins can give you errors, but you can’t get a better type.
• Tuple inferences may be good regardless of this change.
• Can give more specific return types, can validate the string, and even use inference to validate the string.
  • Should make sure the DSL libraries we’re trying to model here are actually tested.
  • But also, the error messages that these produce will be totally unappetizing.
• Conclusion
  • Not 100% sold across the team, but we can convince ourself that it’s reasonable to bring in. Not a priority for TS 4.8, but if it gets in, it gets in.

A Tour of Module Resolution Strategies

https://gist.github.com/andrewbranch/3020c4e24092bd37f7e210d6f050ef26

• Node.js 16+ ESM support was a good focus, but lots of other resolvers that have a non-consistent set of features.
• Been telling people “you need to reference .js as a module extension” for Node.js.
  • If that’s too painful, but maybe you shouldn’t use the new mode if you’re not using Node - but then what should people be doing?
  • Usually the best, most-maximal one is just called, uh, node.
• People using bundlers are often best-off targeting --moduleResolution node.
  • But then every bundler supports the exports field.
  • But then our old node mode doesn’t understand that.
    • Maybe we should pick that into node?
      • Seems like a “duh!” but then…why don’t we see lots of demand for this!?
        • Hypotheses:
          • Relatively uncommon to use exports.
          • ESM/CJS APIs are similar enough.
          • People don’t know how to ask, especially because this is so confusing.
• This is all very confusing - if people are so frustrated, couldn’t we transform paths based on .ts to .js?
  • Always comes up - but it amounts to a transformation from a “TypeScript-specific module system” to several target module systems, and they need to be able to compose well.
    • How do you deal with lies in .d.ts resolution?
    • Do the .ts extensions get preserved in .d.ts files?
    • How does it deal with dynamic imports? Do you need a TS dynamic import helper for non-static imports?
    • How do you refer to dependencies in packages which are exposed as .js files? They aren’t .ts files.
• The point of this table is not to try to model every single bundler behavior, it’s to try to figure out the common module targets and where we have a gap.
• So one of those common targets is places where you don’t need a compiler and the runtime/resolver can do the TS -> JS transform (e.g. Deno, bundlers, etc.).
• No conclusion, but at least feel like we’re getting a better understanding of the lay of the land.

[RyanCavanaugh]

That just moves the problem elsewhere and introduces more configuration. You can’t unconditionally add file extensions – importing from fs/promises should not print fs/promises.js, that won’t work. Yet people can and do use path mappings combined with bundler configuration to make paths that look indistinguishable from that:

import 'vs/editor/editor.all';

so now we need some additional configuration that controls which imports of the form 'a/b' get rewritten to including file extensions. But it’s worse - is the file editor.all.ts, or editor.all/index.ts? Now there’s more information from disk to fetch.

All of this configuration effectively takes us backwards in the journey to making sure files are transpilable without needing extra information from the file system or from other files in the system, which is a key source of performance gain in a ton of scenarios including extant bundlers like esbuild, and our own ability to parallelize emit in the future.

[dummdidumm]

Maybe we should pick that into node?

• Seems like a “duh!” but then…why don’t we see lots of demand for this!?

Consider this a voice of demand then 😄 In SvelteKit we have to keep a somewhat ugly ambient modules hack because of this (similar to @Josh-Cena) (https://github.com/sveltejs/kit/blob/master/packages/kit/types/ambient.d.ts#L71) and we’d very much like to switch to using export maps only instead, which right now doesn’t work because the export resolution is not part of the node resolution algorithm. Since Node 12.X export maps present means they are used regardless of whether or not you use the commonjs or esm resolution, so I feel like a backport makes sense. But I also understand that maybe some people with older Node versions don’t want this behavior, so we need an additional node10 setting now which preserves the old behavior? I certainly don’t envy you 😅

It’s also very strange that we need to reference ambient files (d.ts files) like import "./ambient.js" which feels wrong (is this related to the “lie” statement in the meeting notes?)