Skip to content
New issue

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

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

Already on GitHub? # to your account

Design Meeting Notes, 1/26/2024 #57242

Closed
DanielRosenwasser opened this issue Jan 30, 2024 · 0 comments
Closed

Design Meeting Notes, 1/26/2024 #57242

DanielRosenwasser opened this issue Jan 30, 2024 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Linting Against Unused Locals and Variables

#57123

  • We used noUnusedLocals/noUnusedParameters.
  • Annoying when you comment code, try to run tests, but the build immediately fails.
  • Very annoying.
  • Often people delegate this to a linter, not TypeScript.
  • Switching our codebase to use a linter would mean that linting fails after a test run.
  • But currently we use our own compiler for this logic.
    • In which we process JSDoc nodes for usages to determine if something is "unused".
  • Trying to keep this logic is possible in eslint, but is very slow.
  • Why do you even need to allow these?
    • People using them in @see, @link in TypeScript and relying on import elision.
    • Any other usage in @type in JavaScript files.
  • Alternative: just slap some suppression comments, fix up some code to use import(...) types, call it a day.
    • Sure!
  • But that means we're not dogfooding anymore.
    • But arguably people should be using a linter.
    • So don't have the feature at all?
      • Not convinced there should be a black-or-white view of the world here. These options have value for people who don't want to add more tools.
      • e.g. Other tools build better, but tsc has an emitter.
  • We're okay with switching over.

5.4 Breaking Changes

#57117

Indexing with Intersections of String Literals and String Mapping Types Applied to Non-Generic Strings

Narrowing Conditional

Intersection Reduction

Breaks on Vue

Implementing Functions that Return Conditional Types

#33014

  • Have a PR that allows some return expressions to be assignable to a conditional type.
  • The idea of the change: instead of seeing if the return expression is assignable, we look for if the tested type parameter is used uniquely by a parameter, and instantiate the return type with the narrowed type of the parameter.
  • Most perf doesn't regress from this currently - because nobody is able to use this pattern.
  • Constructed test file seems to do well where
  • Want to get a sense of if we should continue with this concept.
  • Really need to understand what the plan of implementation is. Like the idea at a high level.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jan 30, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants