BREAKING(unstable): remove --compat mode

[bartlomieju]

This commit removes "compat" mode. We shipped support for "npm:" specifier support in v1.25 and that is preferred way to interact with Node code that we will iterate and improve upon. Compat mode adds a loooot of complexity and is ridden with strange bugs.

I'm still not sure about removal of --compat - on one hand removal will break people's CIs, on the other I think it's better to break explicitly than accept this flag which will still break CI.

Effectively all issues below become irrelevant

• Closes Deno panicked at 'assertion failed: (left == right) #15670
• Closes Deno has panicked thread 'main' panicked at 'Provided URL was not file:// URL: #14662
• Closes Deno has panicked error when importing types from index.d.ts file #14413
• Closes compat: deno eval doesn't work with --compat flag #13883
• Closes Panic when running a remote module with --compat #13747
• Closes compat: xregexp doesn't work in compat mode #13424
• Closes compat mode doesn't work with "deno eval" #13002
• Closes Cleanup type checking in "--compat" mode #12482
• Closes compat: libraries can't spawn Deno subprocess properly #13322
• Closes deno bundle and createRequire use absolute paths #12495
• Closes error: Found argument '--max-old-space-size' which wasn't expected, or isn't valid in this context #13945

[bartlomieju]

Raised by @kt3k there's a question of polyfilling child_process.fork. Before merging this PR we need to figure out how to handle that.

[dsherret]

LGTM!

[jsejcksn]

It looks like the manual wasn't updated in step with this change. Is there any process for coordinating changes and manual updates?

[dsherret]

As noted in denoland/manual#388, the manual is being completely rewritten so it's tracked there, but yeah this was missed.

[jsejcksn]

As noted in denoland/manual#388, the manual is being completely rewritten so it's tracked there, but yeah this was missed.

@dsherret Thanks. I'm still interested to know if the rewrite will include some kind of process for coordinating manual updates when changes happen — in order to reduce the likelihood of these misalignments. Is that already the case or not at this time?

[dsherret]

The current process is to update the manual when making a CLI feature change. As stated, this was just missed (probably because it's unstable).