BREAKING: Remove unstable Deno.emit and Deno.formatDiagnostics APIs

[bartlomieju]

Closes #14461

[dsherret]

LGTM

[kitsonk]

I strongly believe we shouldnt remove it until we have an alternative upgrade path. Removing it on a whim us irresponsible and not a sane plan.

[ry]

LGTM

Unfortunately after almost a year of planning we've still been unable to provide a userland version of this. We need to not stagnate on stuff like this - this is a small API used by a small number of projects. Removing it will force development of https://github.com/denoland/deno_emit

This is an unstable API - there was never a promise of continuity.

[jsejcksn]

this is a small API used by a small number of projects

@ry I'm not arguing anything about the decision in this PR, but that comment seems rather nearsighted:

Some APIs are simply not designed for widespread use, and the projects which do use them can have quite massive downstream influence in the ecosystem/community, and so changes to such APIs can actually be very disruptive because of dependency impact. I think it would be beneficial to rethink using that as a metric for future decision-making.

[dsherret]

@jsejcksn IMO that's a bad decision for those projects to depend on unstable APIs in a runtime. The situation is better for them now because they can depend on a versioned API that isn't linked to the runtime at https://github.com/denoland/deno_emit

[jsejcksn]

IMO that's a bad decision for those projects to depend on unstable APIs in a runtime

@dsherret I agree with that, and nothing in my comment was specifically about emit or unstable APIs: rather it was just about factors to consider when making any breaking changes. When considering a "small number of projects", one must consider not just direct dependents but all dependents of dependents recursively, which might be very different than the former.