Repository navigation
Support ".mjs" input files #27957
Description
From Stian Jørgensrud (@Sti2nd) on October 7, 2018 16:17
import { timpaniSounds } from "./soundImport.mjs";
In the above example VS code will show all javascript files when writing "./", but not javascript module files. So I didn't see the above file in the list when trying to import it.
Not sure if this is a bug or a feature request.
Copied from original issue: microsoft/vscode#60103
Activity
mjbvz commentedon Oct 18, 2018
I believe that #18442 tracks compiling typescript to mjs. Do we fully support working with mjs files in the editor?
weswigham commentedon Nov 1, 2018
We don't lookup or include
.mjsfiles in any way at present, since it's going to be used as a flag innodethat changes module resolution and the exact behavior it switches on (W.R.T. cjs interop) is still TBD, interpreting it would be putting the cart before the horse.[-]No autocomplete for ".mjs" files[/-][+]Support ".mjs" input files[/+]weswigham commentedon Nov 1, 2018
Since the other thread tracks
.mjsoutput, I'll repurpose this one for tracking.mjsinput.vincentvictoria commentedon Dec 12, 2018
I think it comes down to a standardization issue: javascript modules must have a standardized file extension.
It's causing troubles to us, and I believe everyone who are making modules targeting for both browser & node are affected.
In browser, we have to specify file name with extension:
import { SuperModule } from './SuperModule.mjs';But vscode doesn't recognize
.mjs, so we resort to changing extension to.esm.jsimport { SuperModule } from './SuperModule.esm.js';Then node doesn't recognize
.esm.jsas a module unless we specify a different loader which recognizes the extension:'node --loader esmloader.js index.js'
This is surely uncomfortable since you have to specify a non-default loader.
Either node has to support
.esm.jsor vscode has to support.mjs. for short-term solution.I personally think module javascript files gotta have a different extension since it's treated differently in both browser & node. Browsers require:
<script type='module' src='script.js' />See, browsers also need to know it's a different type of javascript before loading. I think a different extension is rightful for the purpose.
I prefer
.mjssince it's funny (Hello, Michael Jackson), short and right for the purpose.I'm using
.esm.jsright now, but it's very cumbersome to write. And i have to specify type='module' in the browser anyway even if i already typed '.eeeessssmmmm.js'I just hope es7/8 standard specify that javascript modules must have
.mjsextension.robertrossmann commentedon Dec 12, 2018
I crafted a patch which enables
tsserverto recognise, parse and provide type hints for .mjs files.This might be useful for people who use the .mjs file extensions for JavaScript files with identical module resolution semantics as CommonJS. Note that this patch does not implement any special behaviour with regard to ES modules and might not be spec-compliant. However, editor integrations which allow using custom-built
tsserverimplementations will greatly increase developer productivity because suddenly everything seems to work.101 remaining items
igorskyflyer commentedon Sep 21, 2021
Frank Lemanschik (@frank-dspeed), just to be clear, this:
was never proposed nor supposed to work - as far as I am aware of. The attribute
typewith a value ofmoduleis mandatory for a given JavaScript file to be parsed as a module. Thus, the final code should look like:Also,
.mjsfiles/scripts work perfectly fine after defining their MIME type on the server, tested on XAMPP.frank-dspeed commentedon Sep 21, 2021
Igor Dimitrijević (@igorskyflyer) i did list all requirements including the mime header and in my example i did .mjsOrAny to demonstrate that it has nothing to do with the extension. and your correct without type it is not suposed to work you maybe did not read the whole story.
igorskyflyer commentedon Sep 21, 2021
Frank Lemanschik (@frank-dspeed), my apologies then, I skim-read the comment. Either way, it is evident that we are still waiting for a unique solution for this mjs/modules hell. 😭😅
frank-dspeed commentedon Sep 22, 2021
Igor Novozhilov (@IgorNovozhilov) There is no real module hell anymore the way forward is clear simply drop cjs usage call the files .js and configure typescript correct per folder.
Sure i agree it is a lot to know and do but it is not unsolved at all and .mjs remains a nodejs only topic.
Update for thumbs down
I want to offer some more detailed Information as there are still people who did not get it.
You should create dev-bundels of your dependencies. isolate the packaging of your vendored dependencies from the Main Application that your creating. This will lead to consistent dependencies.
also this got now fixed via a new moduleResolution algo called "node12" as this is a node only thing
weswigham commentedon Sep 24, 2021
Fixed by the addition of
module: node12with #45884 (which includes support for.mjsand.mtsfiles).docs(modules): remove outdated .mjs notes
docs(modules): remove outdated .mjs notes (#9333)
frank-dspeed commentedon Dec 13, 2021
this future will only be in typescript 4.6 it got droped from the 4.5 time schedule #46452 (comment)
as Daniel (TypeScript Team Lead) pointed out
weswigham commentedon Dec 13, 2021
(Technically support did ship in 4.5, it relies on the
module: nodenextsetting, it just issues an error saying it's experimental)frank-dspeed commentedon Dec 13, 2021
Wesley Wigham (@weswigham) does nodenext include everything that was included in node12 (package.json exports fild)?
weswigham commentedon Dec 13, 2021
They're mostly the same (except for some export map edge cases and the implied target), and both modes are included.
knightedcodemonkey commentedon Jul 30, 2023
Is this really fixed? It doesn't seem so, at least not in all use cases. Particularly, there is no way to support a mixture of
.mtsand.tswhen using--module commonjs, all the emitted.mjsfiles will be broken and not consumable by either module system. It is impossible withtscas far as I can tell, so I would not consider this fixed.For the reason why, see my comment on #50985. This should be reopened.
feat: correct module systems by file extension. addresses microsoft/T…
feat: correct module systems by file extension. (#5)