We could use the new Key Remapping Feature of TS 4.1 to our advantage. If it really is feasible needs to be investigated.

If we go that route, we either need to bump svelte-check because we then would require people to use at least TS 4.1, or use the type versions feature (my preference for now to avoid major version bump).

Get better autocompletion by mapping events to $$prop_def

Add the remapped event defs to the $$prop_def. This will also make sure people get autocompletion for events from library components (d.ts only). Currently that is only possible to get from other Svelte components.

$$prop_def: Props & {
        [K in keyof Events as `on:${string & K}`]: Events[K]
    };

TODO:

• handle the : character, handle autocompletion replacements (a quick test shows that it will replace on:f to on:on:foo)
• make sure the whole event string is searched for, not only parts of it (if someone has strange event names like foo:bar)

Update: This is solved by now by traversing the TS AST and retrieving the events map from it.

Simplify code generation for events

We could also use the key remapping feature to simplify code generation for events. We could remap them to something obscure (adding prefixes no human would add) and then leave them as-is as props.

Mapping

$$prop_def: Props & {
        [K in keyof Events as `__on__${string & K}`]: Events[K]
    } & {.. remapping for autocompletion};

New generated code

<Component __on__event={..} />

Ideally we would use the same remapping as for the autocompletion but that won't work because event names are arbitrary and can be in a way that makes an invalid jsx prop. As an alternative, we could try to transform the provided autocompletion (we need to do that to some extend anyway probably) and replace the obscure stuff with the original event string.

TODO:

• make sure every invalid character which cannot appear on a jsx prop (number as first char, :, ...) gets transformed or is left out -> this could be done by transforming the input to base64 and prefix the result with __sveltets_event_ to signal it should be transformed back upon retrieval
• make sure it will work with generics (prop foo is T event on:fooChange is CustomEvent<T>) which will get introduced at some point
• Changing this and not preserving the old behavior would be a breaking change because each library would have to recreate its type definitions
• How to change this in a way that SvelteComponentTyped can still be used with the three generic arguments? -> stringToBase64 is not possible to do here

TypeScript 4.4

We could use the enhanced type signatures to tell svelte2tsx that every property starting with on and not part of the other defined ones is a Custom Event. Question is if that's also too narrow, since theoretically it could be something else.