Closed
Description
Migrating to Modules - Motivations and Goals Sync
- Is it expected that if someone imports
tsc
, will they get something self-contained? - Should we let the bundler run directly on our code, or do we run it on our outputs?
- Do we need to bundle?
- Browsers and Node can handle modules fine.
- We were hoping for optimizations...
- Also, bundling
.d.ts
files? - Also, how will we dogfood our own emit?
- Should try to get things working
Specifiers for Resolution Strategy
- Give
/// <reference
>s a way to say if a resolution should come from arequire
or animport
. - Then the same thing for
import type
with theassert
field. - Who's this for?
- Declaration emit
- Quick info
- So sometimes because export maps are screwed up?
- No, can have correctly set-up import maps.
- Will we generate these in auto-imports?
- We shouldn't generate auto-imports that look like these!
- But declaration emit shares the same logic - so have to make sure that doesn't happen.
- We used to generate a broken import in some cases, now it's better!
- But error messages and quick info - too much info!
- We only fully-qualify if the types have the same exact unqualified string representation.
package.json
Errors in nodenext
- Way to easy to screw up
exports
types
usually needs to come first, but people may put it below.
- Could we provide error messages in
package.json
?- VS Code already provides schema errors.
- Also, can have nested conditions.
- Should this be a project-wide diagnostic, or should it be only a language service issue?
- Is it ever semantically good to have
types
come after everything else? - Unclear what to do - could have JSON language services help here, but that's unlikely.