Skip to content

Design Meeting Notes, 9/28/2022 #51305

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions