I propose to add a mapping of file extension .mjs to mime type "text/javascript".
The "text/javascript" MIME is registered in https://www.iana.org/assignments/media-types, was moved to *should* as the MIME in HTML ( https://github.com/whatwg/html/pull/3096), and is being updated by https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs/

This extension is being used by Node.js for support of ECMAScript Modules (ESM).

New changeset 0854b92cd25613269d21de3cb5239379ddc0f2fb by Andrew Svetlov (Bradley Meck) in branch 'master':
bpo-31715 Add mimetype for extension .mjs (#3908)
https://github.com/python/cpython/commit/0854b92cd25613269d21de3cb5239379ddc0f2fb

I see that when this landed it appears that it was removed from landing on "Python 2.7, Python 3.6, Python 3.7".

Is there any chance to revisit this decision? I dug into the mimetype code and it doesn't appear that there is a way to rely on operating system mimetypes for systems aside from Windows... as such this is going to be a fairly large experience gap for people developing front-end applications that utilize the file extension on any version other than 3.8, which will likely take quite a while to be distributed as a default in various OS distributions.

It's technically a new feature. New features are not added to existing releases unless there is a very compelling reason.

There are a number of tutorials that suggest using the .mjs extension for working with ESM modules for front end development.

https://developers.google.com/web/fundamentals/primers/modules <https://developers.google.com/web/fundamentals/primers/modules>
https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/ <https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/>

There are many tutorials that suggest web developers use `python -m SimpleHTTPServer` as a way to spin up a quick development server.  If a .mjs file is not served with the correct mime type <https://html.spec.whatwg.org/multipage/infrastructure.html#javascript-mime-type> the browser will throw when trying to load the module, and the error is not the most obvious if developers are not aware of what mime types even are.

As such I would like propose that this is a bug fix, rather than a feature, as popular browser workflow is going to be broken without an obvious way to fix it for anyone using python right now.

> On Dec 5, 2018, at 2:23 PM, Christian Heimes <report@bugs.python.org> wrote:
> 
> 
> Christian Heimes <lists@cheimes.de> added the comment:
> 
> It's technically a new feature. New features are not added to existing releases unless there is a very compelling reason.
> 
> ----------
> nosy: +christian.heimes
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31715>
> _______________________________________

Christian Heimes is right: it is a new feature, not a bug fix. 
I regret too often when I cannot backport a brilliant patch to old Python version but this is the price of API stability.

You can try to convince release managers (Benjamin and Ned, I've added you to nosy list) but I suspect you'll get a rejection.

Thanks for cc'ing the other folks. I help run the Node.js release + LTS team... so I 100% understand the balance necessary to keep a stable API. In this particular case I would gauge that this has a near 0 case for breakage, but leaving it unpatched has a high risk of breaking user expectations

https://github.com/search?q=extension%3Amjs+function&type=Code

This is a really heavy handed search against github showing 13k+ files with the .mjs extension that include the word "function"

Also wanted to point out some prior art of a mimetype (json) being backported to all active runtimes

https://bugs.python.org/issue30824#msg297527

We have generally made an exception to the "new feature" rule for mimetypes.  That is, we don't really consider a mimetype addition to be a new feature in the sense that our backward compatibility rules mean.  It is true that an application could work on x.y.z and break on x.y.z-1, but this isn't because an *API* present in x.y.z is not there in x.y.z-1.  is more akin to a bugfix (it threw an exception before, now it works).  Think of the absence of the mimetype rule as a bug, rather than its presence as a feature.

And yes, this is a policy evolution.  This way of looking at mimetypes changes has been in effect for....maybe five years now?...and before that we treated them as features.  But then, too, before that we required there be an actual IANA accepted RFC, but that requirement too has had to evolve as mimetype management became more decentralized.

Thanks for chiming in R. David Murray

> Think of the absence of the mimetype rule as a bug, rather than its presence as a feature.

Very much appreciate this sentiment.

I've opened backports to simplify the process if y'all decide to approve.

2.7: https://github.com/python/cpython/pull/10978
3.6: https://github.com/python/cpython/pull/10976
3.7: https://github.com/python/cpython/pull/10977

New changeset c7b7a43cd8964a90669bb37735cdafc5b0ec60cc by Ned Deily (Myles Borins) in branch '3.7':
[3.7] bpo-31715 Add mimetype for extension .mjs (GH-3908) (GH-10977)
https://github.com/python/cpython/commit/c7b7a43cd8964a90669bb37735cdafc5b0ec60cc

New changeset 70db385944ecf2ceed10ed7d91fce68399f9ca8a by Ned Deily (Myles Borins) in branch '3.6':
[3.6] bpo-31715 Add mimetype for extension .mjs (GH-3908) (GH-10976)
https://github.com/python/cpython/commit/70db385944ecf2ceed10ed7d91fce68399f9ca8a

New changeset d9a2aca839b1326e011ecca17ba7b45123c47a64 by Ned Deily (Myles Borins) in branch '2.7':
[2.7] bpo-31715 Add mimetype for extension .mjs (GH-3908) (GH-10978)
https://github.com/python/cpython/commit/d9a2aca839b1326e011ecca17ba7b45123c47a64

New changeset 25ee15a15c2d274afeea2dc5a0a0b4fb4bea904b by Ned Deily (Myles Borins) in branch '3.7':
[3.7] bpo-31715 Add mimetype for extension .mjs (GH-3908) (GH-10977)
https://github.com/python/cpython/commit/25ee15a15c2d274afeea2dc5a0a0b4fb4bea904b