Skip to content

Design Meeting Notes, 5/21/2021 #44257

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

importsNotUsedAsValues: preserve-exact

#44137

  • People expect import fs from "fs" to compile to import fs from "fs" in importsNotUsedAsValues: preserve

    • We don't - we just preserve the import itself.
  • Came up offhandedly.

  • In places like Svelte, they eval some stuff, do a bunch of hacks to ensure that the imports stick around.

  • The idea: new flag.

    • Same as importsNotUsedAsValues: error.
      • No, that's only an error if you never import a value.
  • The PR stops short of some of the work from last time.

    • Specifically, type modifiers on imports.
      • Would erase away those named imports.

      • How does that play with when you have a default?

        import type fs, { yadda } from "yadda";
        • Ambiguous? Maybe disambiguate with type: fs
        • Not clear that that actually helps at all.
  • Requires es2015+ as a module target.

    • Doesn't make sense for if you're mixing CJS/ESM.
    • The "eval" thing doesn't quite work for our emit anyway.
  • How does tooling work with this?

    • We currently don't "promote" a type import to a value import.
    • A lot of people would prefer not to - sometimes people are using this mode defensively to prevent themselves from bundling more.
      • As long as we can improve in the future and have room.
  • This rule applies to both imports and exports

    import { foo } from "./module.js";
    
    foo();
    
    interace Thing {}
    
    export { Thing };
  • Getting a read for how these options interact is hard.

    • What is the mode that will allow you to be maximally compatible with compilers?
      • --isolatedModules
      • But that won't change things.
  • Meaningful use case: import means value import, import type means erased import.

    • But how do you deal with export { A }?

      • Do you need to write export type { A }?
      • Feels different.
    • Okay, harder case:

      import Yadda from "yadda";
      export { Yadda };
    • Okay, but one is local, we know exactly what it'll be.

    • Not consistent with "leave my imports and exports alone".

    • We seem to feel that a local export {} is exempt from elision rules because the constructs are all local.

  • If TypeScript was a greenfield project, this is probably what our default would be.

    • Would it be?
    • Would we use this ourselves?
    • Managing import vs import type is very annoying.
  • Not super big on giving an error in ES5.

  • Need to think through this a bit more, come up with a coherent write-up.

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