Giters

magento / baler

AMD module bundler and preloader for Magento 2 stores.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mixins are not applied for bundled modules

krzksz opened this issue · comments

commented

Hey! First of all I need to say that I'm really impressed with the performance of this solution an ease of use in relation to other tools which take advantage of headless browsers etc., great work!

Unfortunately, when I gave baler for a spin it seems like we hit the same obstacle that I did and documented under https://github.com/magesuite/magepack#modules-with-mixins-defined-cannot-be-included-in-a-bundle

The issue comes from mixins.js file and its processNames method which is (as far as I understand) responsible for prepending given modules' names with mixins! prefix in case certain module has any mixins defined for it so that they can be applied when it is loaded. The problem is that in order to get a path for said module, getPath is called, which then calls require.toUrl. Multiple calls later we land inside require's nameToUrl method:

nameToUrl: function (moduleName, ext, skipExt) {
                var paths, syms, i, parentModule, url,
                    parentPath, bundleId,
                    pkgMain = getOwn(config.pkgs, moduleName);

                if (pkgMain) {
                    moduleName = pkgMain;
                }

                bundleId = getOwn(bundlesMap, moduleName); // OH NO

                if (bundleId) { // NO NO NO PLEASE NO
                    return context.nameToUrl(bundleId, ext, skipExt);
                }

As you may have figured out, for each of our modules that were included in core bundle we are getting balerbundles/core-bundle instead of the actual name. Because of the fact that stock Magento makes use of mixins, even for providing jquery security patches I would say this issue is critical and should be addressed ASAP before anyone uses this solution in production.

There are 2 possible ways this can be solved:

  1. Don't include modules which have any mixins defined in the bundle, which will hurt performance and I'm not sure if it is even possible to determine that 100% statically.
  2. Make mixins.js bundling-aware by reimplementing whole toUrl to nameToUrl chain so that it doesn't have if (bundleId) { check in it.

That's all that I can see right now, I'll try to hack around a bit to see what the simplest route would be.

commented

Thanks for reporting this! I was able to replicate most of the behavior.

The mixins do get bundled correctly for me (we discussed a bit in Slack), but you're 100% correct that they're not executing, and that is bad.

Trying to free myself up a bit to work on a fix.

commented

Ok, after some hacking around I was able to come up with the form of mixins.js file that applies mixins no matter if modules are bundled or not by using a separate context. Of course it would need some clean-up and adjustments but here it is:
magento/magento2@2.3-develop...krzksz:baler-fix-mixins

commented

Spoke a bit offline, and @krzksz is going to take a stab at fixing this 🎉

commented

@krzksz Had some time to look into your solution tonight - that is super clever! I definitely had not thought of using a separate context for lookups!

I've been playing around a bit with an idea where we could basically compile away mixins and just not need to load mixins.js at all, but it's a pain because we (unfortunately) support setting mixins for shimmed modules, which ends up making that solution super complex vs the savings we get from not loading mixins.js.

I'm going to dig around a bit more and see if we have any more straight-forward options, but my guess is that you've found the most reasonable option. Will follow-up with how we might want to go about landing your changes. We'll obviously want to fix this in core, but we may want to teach baler to patch over the problem in the meantime, to make adoption easier.

commented

@krzksz might even be worth getting a PR to core started up so you can run the test suite (we can always clean up or refactor in the PR)

commented

I'm eager to try Baler, but lack of mixins support is a deal-killer for me. Any update on a fix for this?

commented

@erikhansen There is an open PR to core to address the bug in mixins.js. If you want to get started just apply it as a patch and you're ready to go (thanks to @krzksz)

magento/magento2#25587

commented

@krzksz You're an absolute champ and a lifesaver. Thanks so much.

commented

I have turned the above PR into a patch here: https://github.com/integer-net/magento2-requirejs-bundling

commented

Hi. I just try to use it fix for magento 2.3.4, but seems it is works rather strange - it is works only for mixins that defined in date-mage tags and processed by main.js script. But if you add mixin,which using only in javascript module, this is never appy. Do all mixins work for you ?

commented

Hey @Galillei,

Did you get to the bottom of this? Not sure we're seeing this exact issue but we are seeing strange behaviour on 2.3.4 where a js module just isn't initialising, despite loading and getting defined in an existing bundle

commented

Hey @edward-simpson
Yeah, seems there is same issue.

commented

Hi @jtomaszewski. Based on the above maybe a patche is not needed