Design Meeting Notes, 9/17/2021

[DanielRosenwasser]

Import Assertions

#40698

• Basic idea, adds some additional syntax to import statements.
• Doesn't affect us, we just need to "support" it by ignoring it.
• Allows a runtime to assert that some import shouldn't have any executable code.
• Looks like an object that you can stuff some options into.
• Do we need a global interface that declares the valid properties?
  • This would only affect dynamic import() right?
• Liked the idea of just supporting this and washing our hands of the host-specific details.
  • But seems like any host where this matters would have users savvy enough to add details here.
• Where do these live?
  • JSON is "universally accepted" in TC39, so maybe that goes in lib.es****.d.ts
  • CSS - maybe lib.dom.d.ts.
• How does this affect bundlers vs browser?
  • In theory shouldn't affect things.
  • This is contentious in the community.
  • Not sure what to do about this. 🤷‍♂️
• Feels incomplete to pass in non-string values,
• We'll start with the current changes, then follow-up with stricter types.

Type Display for Unresolved Types

#45893
#38836

• Hover over parameters: we can preserve the type
• Hovering over the type gives you type Thing = any
• Now find all references works at least for within the file.
• Dotted names are trickier.
  • What if you can resolve the namespaces but not the name itself.
• Shying away from the idea of displaying unresolved types differently - we try to preserve what you wrote in print-back.
• Currently only works for types - we could make it work for variables.
  • If we supported variables that are unresolved, it would light up misconfigured JS projects.
  • Deeper properties would be nice!
    • In fact, namespaces and property accesses are necessary to support namespace-style imports (i.e. import * as yadda).
    • Dotted type names, we intend to support.
    • Can speculate we try to create a symbol on the fly for a property.
      • Only aids find-all-refs.
      • Rename too.
        • Might not recommend doing that.
        • Not a safe refactoring.
    • How would you represent this?
      • Global map in checker?
• Doesn't only work in syntax-only mode - also is supported in full semantic mode where code is broken.

[kitsonk]

Regarding import assertions, being a host that is ready to implement it (@denoland) we are totally fine with TypeScript "washing their hands of it" and just allowing it to be parsed. We already do all of our dependency decisioning and resolution outside of tsc and so we only expect the compiler to request the specifier to the host like it always has, and we will worry about if it is code and how to represent it (or not) from a type perspective to the compiler. We believe our only blocker at the moment is that the compiler currently "chokes" on the syntax.

We are ready though to integrate it and give feedback when it lands in the beta.

[DanielRosenwasser]

It's looking more like we will keep ourselves open to being able to check specifiers based on a global type (in the same spirit of ImportMeta. That way, Deno's .d.ts files would be able to communicate exactly which types of imports it supports.

[kitsonk]

Certainly wouldn't argue with that. We have been happy with how ImportMeta works.