@MaartenStaa opened this Pull Request on July 10th 2017

This fixes the error 'Mismatched anonymous define() module' when another identical looking define call occurs on the same page.

In particular, this happened to me in Moodle where there was a define(function() { return g }) from another minified Javascript, causing some kind of conflict with Piwik which happened to also be minified as define(function() { return g }).

@mattab commented on August 3rd 2017 Member

Hi @MaartenStaa
Thanks for the PR.
Do you maybe have a small script that we could use to reproduce the original issue, and see that it has been fixed with your PR?

@sgiehl a couple of tests are failing with:

Piwik\Tests\Integration\JsProxyTest::testPiwik_WhiteLabelledJs_HasNoComment script content (if comment shows, $byteStart value in /js/tracker.php)
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
 /*!! <a class='mention' href='https://github.com/license'>@license</a>-end */

Could it be due to the removal of line endings?

@mattab commented on November 20th 2017 Member

Hi @MaartenStaa
Could you please take a look at my comment above? thanks

@mattab commented on December 14th 2017 Member

As we haven't heard back from @MaartenStaa, will close the pull request for now. If you can, please ask us to re-open or re-create the PR answering the questions, thanks :+1:

@pavelsokolov commented on September 12th 2018

I can confirm that Piwik breaks Moodle js code.

"Uncaught Error: Mismatched anonymous define() module: function(){return g}"

Had to turn Piwik off.

@tsteur commented on September 12th 2018 Member

It be interesting to know if moodle maybe uses JSON3 (http://bestiejs.github.io/json3)? We define 2 modules piwik and JSON3. Looking at https://requirejs.org/docs/errors.html#mismatch there is an explanation for this error:

If you manually code a script tag in HTML to load a script that has a few named modules, but then try to load an anonymous module that ends up having the same name as one of the named modules in the script loaded by the manually coded script tag.

Any chance you can set up an HTML page where we can reproduce this issue?

@yuchi commented on September 13th 2019

@mattab This issue is causing problems on other AMD implementations too. We are seeing this exact problem on Liferay DXP which uses its own AMD Loader implementation.

@tsteur commented on September 15th 2019 Member

@yuchi in case you know how to fix the issue feel free to issue a PR and we can have a look 👍

@yuchi commented on September 16th 2019

Hallo @tsteur, thank you for your quick reply. This PR nails the problem directly, but as far as I see it is solving it by modifying what looks to me as a generated file (js/piwik.*.js).

First of all let’s understand the origin of the issue. A JavaScript file can define() as many modules as it wants, as long as they are all named modules. This is ok because the loader will simply make them available for later use by require(NAME).

Unnamed (aka anonymous) modules are a completely different beast. Since the loader (when called through define) doesn’t know which module is calling him, needs to control very precisely the order of execution, and know beforehand that an anonymous module is going to be loaded.

Usually you “configure” the loader by telling it that a module with the name x can be found at the path libs/x.js but it’s anonymous. When someone requests x, the loader says «ok, I know where it is, let’s load the file» then, when loaded, the loader will receive an anonymous define() and thinks «ok, since I was waiting for the anonymous module x, I expect that this is it».

If a random define() hits the loader when it is not expecting one, that error message arises. Please note that this is the happy path of the problem: a way more subtle and fatal error could happen, when the user requires an anonymous module and piwik loda in the meanwhile, literally hijacking the previous module loading process!

@yuchi commented on September 16th 2019

Since it looks like you are using JSON3 as a dependency, probably there’s some mis-configuration in your bundling process.

Some thoughts without looking at the structure of the codebase here:

  1. Probably JSON3 is not using a clean UMD envelope, messing with the bundler
  2. The bundler is not configured to remove UMD envelopes
  3. You are not using a bundler
  4. You could import an ES2015 or CJS module for JSON3 (given it offers one), but something in the pipeline is not configured correctly

Those are my first ideas to where to find a culprit

@tsteur commented on September 16th 2019 Member

we'll remove JSON3 in Matomo 4 in https://github.com/matomo-org/matomo/issues/6093 anyway so might not do anything for now. IF someone wants to create a PR to fix the issue feel free to do so. Ideally it would not add much additional JS, ideally none to the JS tracker.

@yuchi commented on September 16th 2019

After reviewing the tracker code, it appears to be hand written, and not using any bundler at all.
This PR is the smallest change possible: giving the anonymous module a name. Since there’s no documented build steps to minify the code, the best approach would be for you maintainers to include just the diffs on js/piwik.js and rebuild the rest by yourselves. The failing tests that you saw years ago IMHO could not have been solved by @MaartenStaa, a community member.

@mattab commented on September 24th 2019 Member

Thanks for the feedback @yuchi - would you be able to re-create this PR with naming the module matomo-json instead of piwik-json? we could probably just merge it in the 3.X branch, knowing we likely remove JSON3 in Matomo 4.

Powered by GitHub Issue Mirror