Repository navigation
Design Meeting Notes, 9/17/2021 #45944
Copy link
Copy link
Closed
Labels
Design NotesNotes from our design meetingsNotes from our design meetings
Description
Import Assertions
- 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?
- This would only affect dynamic
- 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.
- JSON is "universally accepted" in TC39, so maybe that goes in
- 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
- 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?
- In fact, namespaces and property accesses are necessary to support namespace-style imports (i.e.
- Doesn't only work in syntax-only mode - also is supported in full semantic mode where code is broken.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Design NotesNotes from our design meetingsNotes from our design meetings
Activity
kitsonk commentedon Sep 17, 2021
Regarding import assertions, being a host that is ready to implement it (Deno (@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
tscand 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 commentedon Sep 17, 2021
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.tsfiles would be able to communicate exactly which types of imports it supports.kitsonk commentedon Sep 18, 2021
Certainly wouldn't argue with that. We have been happy with how
ImportMetaworks.