Support for experimental ".mjs" output

[SMotaal]

Partially Fixes #18442

This PR addresses two aspects of supporting the actual ".mjs" extension:

1. It allows TypeScript to resolve bare specifiers for a file when a respective ".mjs" file can be found, by first looking for a ".mjs" immediately before looking for a ".js" (without affecting any other order).

2. It allows TypeScript to output to ".mjs" only under the following very restrictive config:

{
  "compilerOptions": {
    "module": "esnext",
    "target": "esnext",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true
  }
}

Aside from changes to the source, both harness and baselines have changed to accommodate those two changes, with all current tests passings.

Thanks

[msftclas]

All CLA requirements met.

[SMotaal]

Here are some notes if you are interested in using this PR meanwhile:

https://gist.github.com/smotaal/4f9458cf43cd7a55a12d5c476c15400e

[mhegazy]

We are waiting on node to formalize their support for ES6 modules. I do not think we know if you want .mjs to be the default output (as in this PR) as of yet.
There is also issues with what you can import from and what you can can not, and using which import forms. there are issues with what the declaration file from a .mjs file source should look like, and ultimately we do not know if the solution would be a .mts and .d.mts extension.
Thanks for the PR, but there are many open issues that have not been resolved at the moment, and that is why we have not added this yet.

[SMotaal]

@mhegazy This is intended as a highly experimental step to allow the rest of us in this space to at least explore and experiment, if not to actually be able to do our part in uncovering other less popular edge cases. I realize TypeScript is working hard, but without this very minimal-no-promises-and-just-temporary feature, you are loosing out on all the far more significant potential that other TypeScript users out there could have been bringing to the table (and this is my little contribution)

[SMotaal]

@mhegazy and yeah, I'm a much bigger fan of MJS music thank you (but the alternative is custom loader and so far this needs to be a CLI flag 😱)

[this is how we users feel, we go where we are able/forced to]

[mhegazy]

but without this very minimal-no-promises-and-just-temporary feature,

:D i wish there was that kind of feature.. if a feature is part of the product, ppl will use it and expect it to work, and will be unhappy when their build breaks if the behavior changes.

[mhegazy]

Just to be clear, if .mjs ends up the default for node, we will support it.

The node implementation details are not finalized at the moment. and we do not think we should be making any changes until node plans are stable and clear.

We have two team members on the node modules working group, and we are closely following the development of node module implementation.

[SMotaal]

So let me pick your brain on a temporary workaround for the following:

What would be the most ideal way today to be able to augment my TypeScript development experience in Visual Studio Code so that it would allow me to work with .mjs files interchangeably as it would for other ES2015+.js files (aside from manual .d.ts and to keep it fun, let's assume I can't transpile)

Honestly, I've been racking my brain and others' to solve this, without adding a new layer of the very likely to cause even more incompatibility tomorrow but works today stuff that got us in this desperate mess we are in today.

[mhegazy]

The feature is not supported, that is what #18442 tracks. As i mentioned earlier, we continue to monitor developments on the node side, and we will be adding support as that node module implementation materializes.

[typescript-bot]

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.