Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 2/9/2022 #48016

Closed
DanielRosenwasser opened this issue Feb 23, 2022 · 1 comment
Closed

Design Meeting Notes, 2/9/2022 #48016

DanielRosenwasser opened this issue Feb 23, 2022 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Migrating to Modules - Motivations and Goals Sync

#35210
#46744
#46567

  • 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

#47732
#47807

  • Give /// <reference>s a way to say if a resolution should come from a require or an import.
  • Then the same thing for import type with the assert 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

#46861

  • 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.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Feb 23, 2022
@Jack-Works
Copy link
Contributor

types usually needs to come first

I wonder why

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants