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, 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
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