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, 5/21/2021 #44257

Closed
DanielRosenwasser opened this issue May 25, 2021 · 1 comment
Closed

Design Meeting Notes, 5/21/2021 #44257

DanielRosenwasser opened this issue May 25, 2021 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

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.

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label May 25, 2021
@dmichon-msft
Copy link
Contributor

The addition of import type and export type really needs a companion flag that errors when using regular import or export with an interface or type. Something to automate the conversion process and provide enforcement.

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