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, 9/28/2022 #51305

Closed
DanielRosenwasser opened this issue Oct 25, 2022 · 0 comments
Closed

Design Meeting Notes, 9/28/2022 #51305

DanielRosenwasser opened this issue Oct 25, 2022 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Oct 25, 2022

More Accurate Checking on Merged Aliases

#50853

// a.ts
export const X = 1234;

// b.ts
import { X } from "./a"
export type X = number

// c.ts
import { X } from "./b";
const x: X = X;
//           ~
// Today, we report
// 'X' only refers to a type and not a value.
  • There are some weird mechanics at play here. We stop at the first non-export/import.
  • Our usual alias resolution strategy - where we keep going until we find some non-alias - is wrong, because somewhere deeper, you might end up with an alias.
  • Some similar weird stuff with namespaces/internal modules was the only case we could think of where stuff broke.
  • The skipping behavior we have here - should we provide that to a user?
    • You always need the non-skipping behavior, API consumers can build the skipping behavior on top of that.

      /** Follow all aliases to get the original symbol. */
      getAliasedSymbol(symbol: Symbol): Symbol;
      /** Follow a *single* alias to get the immediately aliased symbol. */
      getImmediateAliasedSymbol(symbol: Symbol): Symbol | undefined;
      • getAliasedSymbol is more like getFirstNonAliasedSymbol
  • Is this a break? Seems like these are just bug fixes?
    • Target for 4.9.

Module Resolution --minimal

#50153

  • Subtleties.
    • No special resolution to node_modules.
    • Have to remove special behavior in auto-imports.
    • That means we always generate a relative path to ./node_modules/@types
      • Because there's also no special behavior for @types.
  • Stuff stops working.
    • The entire @types scheme doesn't work for this mode.
    • typesVersions and types@ selectors in exports don't work with this.
      • Because we wouldn't look in package.json anymore.
      • There's ways to support this maybe.
        • The relativePaths option suggested in the issue can do that - map to the specific subdirectory that targets a version in a package.
  • So what are we going to do about node_modules here?
    • Allow relative paths, but do something special for @types and hope the packages perfectly mirror?
    • Disallow relative imports to node_modules?
  • node_modules will be the thing lots of people just want to fall back to, right?
    • How would a user want this to be served from a web server?
  • If we want to allow resolution from node_modules, then DefinitelyTyped needs to really enforce the file structure that a package was authored in.
  • Having a hard time knowing how people want to use this.
  • How does Deno solve the types versioning problem?
    • They're always running directly on source.
    • A CDN can redirect in theory, but we're not sure.
  • May try to split out the useful stuff and focus on bundler mode.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Oct 25, 2022
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