jsr publish --fix

[lucacasonato]

I think that we can auto fix the majority of slow types diagnostics (missing return types, and explicit class types) by using TSC inference and then fixing up the source code with the explicit types gotten from TSC.

This is a bit of work, but would make supporting types in your package a matter of jsr publish --fix (or deno lint --fix). Right now the wall of slow types errors could be a bit daunting.

[KnorpelSenf]

Why would --fix not be the default?

[paulmillr]

@KnorpelSenf I don't want jsr to mess with my shit by default

[vwkd]

Not necessarily implied by the description, but I too suspect modifying code on-the-fly while publishing might not be a good idea.

This could open a can of worms where the code in the repo and the published code start to diverge, if not all modifications are bijective transformations and the published code is ever used as the repo code. Maybe unlikely to occur, but one could imagine some scenario where the published code is used to restore a repo that was somehow deleted or lost. Maintaining this subtle contract might be difficult as TypeScript and JavaScript evolve over the years, as it takes only one non-bijective transformation to break it.

I'd prefer if it modified the local copy of the code such that it can be committed to the repo and publish can remain a simple upload of the exact local code.

[KnorpelSenf]

So it seems like implementing this in deno lint --fix would be the best option

[Swimburger]

So it seems like implementing this in deno lint --fix would be the best option

If the jsr publish command does linting, there should also be a jsr lint or jsr publish lint, including a --fix argument.
deno lint --fix also makes sense, but jsr users should not have to install deno.