Design Meeting Notes, 4/13/2022

[DanielRosenwasser]

Resolution mode assertions for import type

#48644

(notes in this section from @RyanCavanaugh with some edits from me)

• Controls how resolution acts - import-style, or require-style
• Pushback from some community members about whether this is an appropriate use of assertion syntax
• Caveat: import type is "our" syntax - doesn't work elsewhere
• Real import assertions are after-the-fact checks, not behavioral modifiers
• Alternatives?
  • Comment directives
  • Dotted names like import.require and import.import (nonstarter)
  • Invent our own different keywords
• This might be confusing for users
• Deno may care because... they have semantic comments too?
• Additional configuration properties might need to appear here in the future
• Would using a more clearly-TS property name in this position assuage concerns?
  • Unclear, but probably no - the argument seems to center around the use of assert syntax.
• By re-using assert, other tools don't need new syntactic handling
• We use other JS-apparent syntax ({ x: y }, etc)
• What happens if we add import type to JS?
  • The assertion would also be ignored, resolution would never even occur
• What alternatives were considered during implementation?
  • Various comments, as
• Sidebar: Why do real import assertions exist?
  • Validation
• The spec says you can't use assertions as a cache key, i.e. you can't use it to modify resolution, but we're using it for exactly that - seems bad
• What about rewriting the name to include a custom protocol?
  • Super dangerous; we can't predict what this will look like
• What happens if we don't emit these kind of paths?
  • You get the "this path is non-portable" error
• We don't want multiple ways to do this
• How usable is node esm without this?
  • ??
• Can we just wait for CJS to go away?
  • ???
• Other third-party tools will be mad if we add new rando syntax they have to deal with just for this.
• Can we fix this with compile-time decorators?
• Idea: possibly gate this syntax to nightly-only, emit an error upon use.

Stage 3 Decorator Placement

• Our support for decorators originally placed decorators coming before the export keyword.

  • ECMA-262 direction is that the syntax would be

    export default
    @someDecorator1
    @someDecorator2
    class Foo {
    
    }

• The placement of fields on our objects is sensitive to their positions. We always expect specific fields to come before others so that we can correctly do source-maps, syntax tree printing, etc.
  • So can't mix export and default into the same bag as abstract when they're split up by decorators preceding them.
• Idea
  • Split between leadingModifiers and trailingModifiers
  • API needs to provide modifiers as [...leadingModifiers, ...trailingModifiers]
  • Still creates a lot of breaking changes.
• The changes here are cumbersome, and changes whatever API users might expect.
• Would it make sense to have leading/trailing decorators instead?
  • No, still need to split the modifiers.
• TC39 seems pretty resistant to take any feedback from us on this. 😕
  • Seems unfortunate since this affects, Prettier, ESLint, etc. too.