Anyone? The issue won't fix itself 😄

Hi @nbelyh,

thanks for reporting! 👍🏻

Any chance you could make that reproduction available as a github.com repository? ..I've gotten the habit of not opening .zip archives from the internetz over the years 😸

@phillipj thank you for response!
I just thought that creating a repository to reproduce a single issue may be a bit of an overkill 😄
Isn't opening zip files (not executables) safe?

Anyway, here is the repo (using 4.2.0):
https://github.com/nbelyh/repro-mustache-402

npm install
npm start (just launches webpack)

After that, open (double-click) the file index.html => error in the browser console (from the description)
If you change the version to the previous one, 4.1.0 like this:

npm install mustache@4.1.0
npm start

Then the file opens fine (no errors)

@phillipj forgot to make the repo public - now it should be

Sorry for the late reply, and thanks for reporting!

You've definitively hit an unexpected side effect that we did not consider when introducing the package.json/exports field in #773. Those changes seems to make webpack choose the .mjs with ES Modules syntax instead of .js, and the consequence is slighty different semantics when importing mustache.js.

Gotta dive deeper and compare pros/cons on plausible solutions going forward, in the meantime if you want to stay on mustache.js 4.2.0, the following does the trick and makes sense having the mustache.js' source code in mind:

import mustache from "mustache"

@phillipj Thank you for quick response!
Unfortunately, this import syntax requires esModuleInterop=true in tsconfig (this issue is about typescript). It is not always possible to have it like this, as it may conflict with other imports. For now I've decided to stay with 4.1.0...

Unfortunately, this import syntax requires esModuleInterop=true in tsconfig (this issue is about typescript). It is not always possible to have it like this, as it may conflict with other imports.

Huh, that's weird, as I was able to use the import I suggested in that reproduction repository of yours, without any other changes.

For now I've decided to stay with 4.1.0...

Alrighty 👍

Yes you are right, it works in this repository without this directive. I faced the problem with this import in another project, will check it there and hopefully come back with more details. Maybe typescript version...

We've hit the same issue now, fairly unexpectedly I must say. We used mustache in many places before, and it was the go-to-templater.

• TypeScript 4.1.3
• Webpack 5.21.2
• mustache.js 4.2.0

We have esModuleInterop explicitly enabled in our projects.

Gotta dive deeper and compare pros/cons on plausible solutions going forward, in the meantime if you want to stay on mustache.js 4.2.0, the following does the trick and makes sense having the mustache.js' source code in mind:

I'm reading this that it is for us probably better to now adjust to this import syntax through a global search-replace run, and that this will stay supported? Would it be good to possibly add a note in README.md pointing this out?

import * as Mustache from 'mustache';

   container.innerHTML = Mustache.default.render(container.innerHTML, {
      balance: 30,
    });

this works ( I donno why), but type definitions are messed up :/

Reverting to 4.1.0, until 4.2.0 is solved. I'm getting this error in Chrome:

yes, this this a major breaking change for those of us using mustache in a very simple <script type="text/javascript" src="js/mustache.4.1.0.js"></script> sort of way. The 4.2.0 file is invalid unless imported as type="module", which, while the "modern" way to do native module support, is definitely a forced change.

Hi folks,

my lack of responses and alternatives to fix this properly is a result of me not having the time to do much open source in my spare time these days. I'm obviously sorry for the frustration and wasted hours this has caused for you.

Your reports are certainly valuable and needed to ensure we consider more usage scenarios than what we obviously had in mind when doing the 4.2.0 release -- we honestly tried our best to consider everything, but failed.

Now that we do have a few added scenarios to consider, it feels the most valuable contribution going forward would be ideas of what is wrong and what could be done differently. My capacity isn't going to change in the near future, so in the spirit of open source, this needs to be fixed by collaborating around thoughts and/or concrete changes to the code or build process.

Bottom line: help mustache.js get this right please?

@phillipj totally understandable. I'm no javascript wiz, but I'll take a look at the repo and its build process when I have a chance and see what I can come up with. It might be that mustache.js needs to provide a couple of variants, built for specific tool-chains.