Magento 2 Extension Experience (Quick Note)

This is just a quick preview of the likely experience for extension developers who wish to list their extensions (or themes) on the new Magento Connect (TNMC). A part of this is describing how the Magento 2 installation wizard interacts with Composer. Official documentation is coming – this post is just to give a super quick overview to demistify what is going to be involved.

For Extension Developers

Firstly, all extensions listed on TNMC will be uploaded (for M2) as a set of Composer packages in ZIP format. That is, you create a ZIP file for each module of the directory where the composer.json file is (the root of your module directory).

If your extension consists of multiple modules, you upload one package per module.

One “root” package will be uploaded with associated “extension” metadata for including in the store. (E.g. extension description, price, etc.) You don’t have to repeat this for each module in a multi-module extension.

Composer packages have version numbers. If you need to release a patch, you create a new ZIP for the new version and upload that.

To Install for First Time

You will be able to use composer to create a new project from scratch, but it will be a bit slow. Because of this, we are considering having a pre-built ZIP or tar ball of a base CE installation which you then upgrade as required to newer patch levels.

To Install an Extension

To install an extension, you can use the installation wizard. There is a section called “component manager”. This connects to the Composer repo and downloads the “packages.json” file. It uses this to tell you what you have installed or not installed. It will let you update modules.

CE and EE will be shipped as a metapackage pointing at all the modules to include. The component manager knows this, and will display the parent metapackage with packages (if there is one). (Later this might turn into an expand/collapse tree view.)

Extensions will likely be recommended to do the same if you have more than one package – create a parent metapackage, if only because it helps the component manager know the packages that form the extension.

If you purchase an extension, it will be added to the packages.json file for your account. Using component manager you can add a dependency to the new composer package (with correspondeing) composer.json file and download the extension using Composer.

Conclusion

In summary, creating Composer packages for a working module is to basically ZIP the directory tree up.

The installation experience using the instllation wizard will be controlled by a packages.json file retrieved by Composer. But it is basically using Composer tools.

More details are coming. Until then, hopefully this post answers a few questions.

7 comments

  1. foomannz · · Reply

    Thanks Alan, this clears up some things. What I still can’t work out though is, what about external dependencies? For example on M1 one of my extensions included a third party library and I had to include the complete code in the extension to be able to distribute through Connect.

    Ideally what I would like instead be able to do is upload an extension to Connect which has a dependency on a library available through packagist. Will this be supported? Or will everything need to be available (duplicated) through the Magento distributed packages.json?

    1. Your extension can have multiple packages. We have been wondering about security checks for third party libraries – we may need to whitelist some.

      What library is it? We put extensions through security audits – so there is a question on how to deal with such packages. We were wondering if we need to cache a copy of particular versions of external libraries so we can put through security scan (but not code style check). A concrete real use case would be useful for us to experiment with.

      1. We have been using the tcpdf library (I have a forked version on packagist) to work around a load time issue when using Magento’s DI for one of our extensions. I will submit this extension shortly for verification so you can take a look.

        Another extension of mine used the minify library in the past (currently no concrete plans for M2 on this one).

        However you already have a perfect example in your own repository to experiment with: http://packages.magento.com/_packages/magento_module-braintree-1.0.0-beta4.zip which has a composer.json requiring braintree/braintree_php which I currently do not see on packages.magento.com and it only works because the require got merged into the root Magento composer.json. Imagine this needing to be a standalone extension installed separately.

        Further use cases: Payment Gateways, Shipping Carriers, really anything that provides a standard PHP library to consume an API (the Magento extension then really only needs to provide the code to bridge the two)

        Also take a look at some of the early M2 extensions by Cyrill
        https://github.com/SchumacherFM/Magento2-Twig/blob/master/composer.json#L8
        https://github.com/SchumacherFM/Magento2-Markdown/blob/master/composer.json#L9

        In summary it currently sounds like only if you have access to the root composer.json file you are able to easily include a third party library dependency (ie only Magento Core and SIs).

        Overall I think some policy needs to be worked out on how to include libraries not available via Magento’s packages.json as the big appeal of composer is to be able to re-use any components from anywhere in the php world. Not being able to include these easily in an extension (currently it sounds like I would need to clone and then create a zipped version to be uploaded into Connect) is negating quite a bit of the benefits that come with Composer.

        Whitelisting and running standard security checks on them sounds like a good idea.

      2. Thx! We will review internally.

  2. I realize there is a need for a non-vcs method (not everyone has/pays for a repo), but it would be nice if a webhook could be incorporated. That way when a new tag is released, TNMC could download itself a copy and do what it needs to do. It would make integration with existing GitHub/BitBucket modules seamless.

    1. Thx for suggestion. Can certainly look at this sort of thing for future.

  3. In magento 1, I have used addCss function to add css file to head. However, I don’t see this fucntion in magento 2. Can you help me?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: