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, 3/29/2024 #58412

Open
DanielRosenwasser opened this issue May 2, 2024 · 0 comments
Open

Design Meeting Notes, 3/29/2024 #58412

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

Comments

@DanielRosenwasser
Copy link
Member

When should you be able to implicitly return undefined

#57912

  • We allow people to implicitly return when a type
    • is undefined.
  • But no implicit returns when you have 4 | undefined
    • More importantly, you can't do Promise<undefined> | undefined.
  • Let's revisit.

Knip

#56817

  • Unused code detector - unused code, unreferenced dependencies, etc.
  • Used on DefinitelyTyped tools.
  • Is able to flag/fix utilities that shouldn't be exported.
  • We do like the idea of adding this - the CI time is a bit higher and that does make our workflow for bisecting a bit painful.
    • Considering adding it purely in CI and purely on-demand by the team; but not part of devDependencies.

Using const enums in value space when using --preserveConstEnums

#57996

  • We have all these restrictions around being able to reference const enum declarations as direct values.

    const enum E {
      A = 123,
    }
    
    let x = E; // ❌
    • We get around this by writing (ts as any).SomeEnum
    • It works because we use preserveConstEnums.
  • Recently Allow cross-project references to const enums in isolatedModules when referenced project has preserveConstEnums #57914 got merged, says that you can reference const enum members from another project under isolatedDeclarations if the project has preserveConstEnums enabled.

    • This effectively gives us some of the same checks to determine if it's safe to reference the enum declaration itself across files.
      • Something we could do within a project before, but not across. Now we can do both.
  • We need this ourselves to enable isolatedDeclarations

  • Doesn't esbuild just inline enums unconditionally? Regardless of const-ness?

    • Could just switch these all to regular enums, turn off preserveConstEnums
    • That means we'd always take a perf hit in services from enums declared in compiler.
      • Or in general?
      • Maybe acceptable.
    • What happens if we start emitting to pure ESM with no bundling?
      • Perf hit!
  • In principal, don't like looking up compiler settings from dependency projects.

  • Well we can do what we want, but the request came externally.

  • We preserved originally only for debugging purposes.

  • Not totally against, this, but some of us feel like our own codebase would be better served from dropping const from our enums.

  • Also you want consumers not to inline, but you also don't want @foo/package-a and @foo/package-b not to inline between each other.

  • Revisit.

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label May 2, 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

1 participant