question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Refactor `Magento_BundleConfig` module to follow best-practices

See original GitHub issue

This issue is a:

  • Bug
  • Feature suggestion
  • Documentation issue
  • Other (Code Quality task)

Environment

Question Answer
Magento version N/A
Browser + version N/A
node.js version (node -v) N/A
npm version (npm -v) N/A

Description

The Magento_BundleConfig module was authored by me. I barely know PHP, and I certainly don’t know best-practices for m2 modules. The majority of this code is copy/pasted from Magento_RequireJs in core.

Expected result:

Magento_BundleConfig is refactored to follow Magento module best-practices.

Possible solutions:

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:14 (9 by maintainers)

github_iconTop GitHub Comments

1reaction
Vinaicommented, Dec 11, 2018

@DrewML Thanks for the great response, you explained it much clearer than I could have done that.

Also thank you regarding your comments on defer. It would probably be the right choice, but interestingly async is working well for us currently. Still probably will change that when I get a chance to work on the project again and refactor.

defer is currently not added by Magento_BundleConfig because there is at least 1 script in a default m2 installation in the body that expects certain modules to be available synchronously.

True, so far I added a path config to a patched version that wraps it in a define().

1reaction
aligent-lturnercommented, Dec 10, 2018

I’ll just piggy-back onto this existing issue, since the things I’ve noticed probably fall under refactoring:

  1. Folder structure needs to be of the form <Vendor>/<Module>, so should be Magento/BundleConfig, rather than just Magento_BundleConfig.
  2. etc/module.xml requires the module tag to have a setup_version attribute (in the form x.x.x) - without this, bin/magento commands fail (as it reads module information each time). You can use whatever numbering scheme you want (e.g. <module name="Magento_BundleConfig" setup_version="0.1.0">)
Read more comments on GitHub >

github_iconTop Results From Across the Web

The integer_net solution to Magento 2 JavaScript bundling
The BundleConfig module will inject your bundles into the head of Magento, and we don't want that. So remove or disable the module...
Read more >
Javascript Bundling in Magento 2
Javascript bundling is a technique that groups separate files in order to reduce the number of HTTP requests that are required to load...
Read more >
Magento 2 Javascript Bundling with Magepack
This method determines whether the magepack module is enabled and if bundling should be activated. Simply detect any page here i.e. checkout ...
Read more >
Optimizing Magento 2 Website Performance.pdf
In this whitepaper, we will discuss about optimizing the page load speeds of. Magento based e-commerce stores using Magepack Bundling, an open source ......
Read more >
Rules for Designing a High-Quality Magento 2 Module
To ensure that a custom module does not break any existing features, it is very good practice to switch between production and development ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found