bundles not generated when s:s:d run with `-s compact`

[maaarghk]

trace output:

(450.8348079994321): Resolving dependency "jquery/jquery.mobile.custom" from "unknown source"
(450.95511799678206): Resolving dependency "mage/common" from "unknown source"
(451.0416179969907): Resolving dependency "mage/dataPost" from "unknown source"
[...]
(452.7179719991982): Resolving dependency "Magento_Catalog/js/more-less" from "unknown source"
(452.83620499819517): Preparing to analyze "jquery/jquery.mobile.custom" for dependencies
(453.26991099864244): Warning for missing dependency "jquery/jquery.mobile.custom", which was required by "<entry point>"
(453.3077109977603): Preparing to analyze "mage/common" for dependencies
(453.3644319996238): Warning for missing dependency "mage/common", which was required by "<entry point>"
(453.37505899742246): Preparing to analyze "mage/dataPost" for dependencies
(453.4178909994662): Warning for missing dependency "mage/dataPost", which was required by "<entry point>"
[...]
(468.5774130001664): Resolving dependency "Magento_Catalog/js/more-less" from "unknown source"

baler then gets stuck in an endless loop.

[maaarghk]

@DrewML just out of curiosity, and if it can be answered quickly and without too much investigation - is this a fundamental limitation of the method or just a case of the dependency resolver needing updated with additional functionality?

[DrewML]

Hey @maaarghk, thanks for the report.

I could have sworn I had this documented, but apparently not! At this time, there is no official support for the compact static content deployment strategy.

The original plan was to re-write static content deploy and get rid of the compact strategy entirely. TBH, I'm not super sold on supporting compact, but of course I'm open to further feedback on this.

Although it speeds up deployments, it has a performance impact on shoppers in the storefront. One of the goals of this project is to improve storefront performance, so I'm cautious about supporting Magento configurations that can negatively impact the user experience further.

[maaarghk]

Thanks for the feedback! We would have static content cached at the CDN edge so don't expect the storefront performance to suffer. Is there something else about compact which I'm missing here?

[DrewML]

Is there something else about compact which I'm missing here?

I'm no expert, so feel free to point out if I'm wrong here :)

Last I checked, compact generated a file called requirejs-map.js. Instead of using symlinks on the server or server-side rewrites, the store ships a list of all mappings to a shopper.

This is troubling because:

1. requirejs-map.js must be downloaded and executed before any modules can be downloaded
2. The size of requirejs-map.js is on average (from what I've seen) over 100kb when uncompressed, which is big

[maaarghk]

Me neither :) Thanks for the info!

[DrewML]

@maaarghk no problem!

Going to leave this ticket open now to track pending work.

TODO:

• Update docs explaining that compact is not supported, with a brief explanation as to why
• Detect when pub/static has been deployed with compact strategy and warn + exit, instead of just running endlessly