Fix RequireJS min resolver for unbundled contexts

[GrassH]

Description (*)

ACP2E-4058 made the mage/requirejs/mixins.js unbundled RequireJS context reuse the default context nameToUrl resolver so minified URLs are generated correctly.

That fixed minified URL generation for the unbundled context, but it also copied default context bundle resolution into that
context. As a result, bundled modules can resolve to bundle paths during mixin lookup instead of their original module IDs. For example, a module configured as:

'Magento_Checkout/js/view/billing-address'

can resolve to:

'bundles/checkout'

Mixin configuration is keyed by the original module name, so mixins.getMixins('bundles/checkout') returns no mixins even though mixins.getMixins('Magento_Checkout/js/view/billing-address') would return the configured mixins.

This pull request moves the minification behavior to the generated min resolver instead of sharing the default context resolver with the unbundled mixins context.

The generated min resolver now decorates each RequireJS context's own nameToUrl implementation, including contexts created after the resolver is loaded through require.s.newContext. This preserves minified URL rewriting while keeping each context's own resolution behavior.

The change also removes the direct nameToUrl assignment from mixins.js and prevents bundles config from being forwarded into the unbundled mixins context during later require.config() calls.

This preserves the intended separation:

• default context: handles normal module loading, including bundles and minified URLs
• unbundled mixins context: resolves original module paths for mixin lookup, without bundle assignments, while still getting minified URL rewriting

Related Pull Requests

N/A

Fixed Issues (if relevant)

1. Fixes RequireJS mixins fail for bundled modules after ACP2E-4058 nameToUrl change #41071

Manual testing scenarios (*)

1. Enable JavaScript minification.
2. Configure a RequireJS bundle that contains a module with a configured mixin, for example:

var config = {
   bundles: {
       'bundles/checkout': [
           'Magento_Checkout/js/view/billing-address',
           'Vendor_Module/js/view/billing-address-mixin'
       ]
   },
   config: {
       mixins: {
           'Magento_Checkout/js/view/billing-address': {
               'Vendor_Module/js/view/billing-address-mixin': true
           }
       }
   }
};

3. Open a page that loads the bundled module.
4. Confirm in the browser console that the unbundled mixins context resolves the original module path instead of the bundle path:

require(['mixins'], function (mixins) {
   var name = 'Magento_Checkout/js/view/billing-address';
   var url = require.s.contexts.$.require.toUrl(name);
   var path = url
       .replace(require.s.contexts._.config.baseUrl, '')
       .replace(/\.js$/, '');

   console.log({
       resolvedPath: path,
       mixinsByName: mixins.getMixins(name),
       mixinsByResolvedPath: mixins.getMixins(path)
   });
});

5. Expected result:

   • resolvedPath remains the original module path, not the bundle path.
   • configured mixins are applied to the target module.
   • no non-minified JS resources are requested when JS minification is enabled.

6. Confirm checkout or another page using bundled RequireJS mixins renders without missing mixin-provided component properties.

Questions or comments

This pull request intentionally fixes the minification resolver layer rather than adding a fallback in mixins.js.

The previous approach made the unbundled mixins context reuse the default context resolver. That solved minified URL
generation, but it also leaked bundle resolution into a context that is specifically intended to resolve original module paths
for mixin lookup.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @GrassH. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[GrassH]

@magento run all tests

[GrassH]

@magento run Static Tests

[GrassH]

I reviewed the failed test reports for Functional CE, Functional B2B, Functional EE, and WebApi.

The failures do not appear to be related to this PR. This PR only changes RequireJS config/min resolver behavior and the
related RequireJS mixins test coverage.

The only related failure was in Statics:

• PHPCS warnings in lib/internal/Magento/Framework/RequireJs/Config.php
• PHPStan warning for an unreachable empty() branch in getMinResolverCode()

These static issues have been fixed in commit 895783f.

Other failures are unrelated:

• Adobe Stock functional failures are caused by the test expecting #adobe-stock-tabs, but the selected Adobe Stock image did
  not render model tabs.
• WebApi failures are caused by downloadable_domains env.php configuration for downloadable product links.
• B2B/CE functional failures are in checkout, coupon, shared catalog, wishlist, negotiable quote, and admin order flows, with
  missing expected page elements or messages. These modules/flows are not modified by this PR, and there is no RequireJS/module
  loading error in the reports.

Given the failure locations and messages, these should be treated as unrelated flaky/environment/test-data failures or handled
by the corresponding test/module owners.

[GrassH]

@magento run all tests

[GrassH]

@magento run all tests