Repository navigation
Support ".mjs" input files #27957
Description
Activity
- addedDomain: JavaScriptThe issue relates to JavaScript specificallyThe issue relates to JavaScript specificallyand removedDomain: JavaScriptThe issue relates to JavaScript specificallyThe issue relates to JavaScript specifically
on Oct 18, 2018 - addedVS Code TrackedThere is a VS Code equivalent to this issueThere is a VS Code equivalent to this issue
on Oct 18, 2018 I believe that #18442 tracks compiling typescript to mjs. Do we fully support working with mjs files in the editor?
Reacted by Dan Dascalescu and ExE BossReacted by fartwhif- removedVS Code TrackedThere is a VS Code equivalent to this issueThere is a VS Code equivalent to this issue
on 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.Reacted by fartwhif- addedSuggestionAn idea for TypeScriptAn idea for TypeScriptIn DiscussionNot yet reached consensusNot yet reached consensus
on Nov 1, 2018 - changed the title
[-]No autocomplete for ".mjs" files[/-][+]Support ".mjs" input files[/+]on Nov 1, 2018 Since the other thread tracks
.mjsoutput, I'll repurpose this one for tracking.mjsinput.Reacted by Dan Dascalescu, Justin Grant, ExE Boss, Brian Takita and Blake StephensReacted by fartwhifI 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.js
import { 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.Reacted by fartwhifrobertrossmann commented
on Dec 12, 2018 More actionsI 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.Reacted by Yevhen, ExE Boss, Nabil Redmann, Adarsh Madrecha and dPowNextdoorReacted by fartwhif101 remaining items
Frank Lemanschik (@frank-dspeed), just to be clear, this:
<script src="/myModule.mjs"></script>
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:<script src="/myModule.mjs" type="module"></script>
Also,
.mjsfiles/scripts work perfectly fine after defining their MIME type on the server, tested on XAMPP.Reacted by Frank LemanschikReacted by Frank LemanschikIgor 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.
Reacted by Igor Dimitrijević and Rafael HenglesFrank 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. 😭😅
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
Reacted by Gili TzabariReacted by Sean Genabe, Rafael Hengles and Cecile MullerFixed by the addition of
module: node12with #45884 (which includes support for.mjsand.mtsfiles).Reacted by Tim van der Lippe, Kenta Moriuchi, Bo Lingen, Rafael Hengles, Anton Trofymenko, ExE Boss, Jason Williams and Robert RossmannReacted by Max Milton, zioroboco, Bo Lingen, Rafael Hengles, Igor Dimitrijević, Steve Miller, ExE Boss, Romain Lamothe, ttyobi, Jason Williams and 1 more- added a commit that references this issue
on Sep 29, 2021 - added a commit that references this issue
on Sep 29, 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
(Technically support did ship in 4.5, it relies on the
module: nodenextsetting, it just issues an error saying it's experimental)Reacted by Frank LemanschikWesley Wigham (@weswigham) does nodenext include everything that was included in node12 (package.json exports fild)?
They're mostly the same (except for some export map edge cases and the implied target), and both modes are included.
Reacted by fartwhifIs 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.
Reacted by Penn Su
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