Developers tool for WordPress plugins: Wraps all your projects dependencies in your own namespace

Overview

Mozart Latest Stable Version License Total Downloads Docker Image Pulls

Composes all dependencies as a package inside a WordPress plugin. Load packages through Composer and have them wrapped inside your own namespace. Gone are the days when plugins could load conflicting versions of the same package, resulting in hard to reproduce bugs.

This package requires PHP 7.3 or higher in order to run the tool. You can use the resulting files as a bundle, requiring any PHP version you like, even PHP 5.2.

Warning: This package is very experimental and breaking changes are very likely until version 1.0.0 is tagged. Use with caution, always wear a helmet when using this in production environments.

Installation

Mozart brings its own dependencies to the table and that potentially introduces its own problems (yes, I realise how meta that is, for a package like this). That's why installing Mozart in isolation, either through the Docker container, the available PHAR file or installing Mozart as a global dependency with Composer is prefered. In all cases, the configuration still needs to be placed in the composer.json file of the project iself.

Docker

Pull the Docker image from the registry:

docker pull coenjacobs/mozart

Then you can start the container and run the mozart compose command in the container. In a single command:

docker run --rm -it -v ${PWD}:/project/ coenjacobs/mozart /mozart/bin/mozart compose

Above command automatically adds the current working directory as a volume into the designated directory for the project: /project/. In the Docker container, Mozart is installed in the /mozart/ directory. Using the above command will run Mozart on the current working directory.

Please note that the Docker image for Mozart is only available starting from the latest build of version 0.7.0. The latest tag is always the latest build of the master branch and not a stable version. You can see all available tags on Docker Hub.

PHAR (via Phive)

Mozart can be installed via Phive:

phive install coenjacobs/mozart --force-accept-unsigned

Alternatively, the mozart.phar file can be downloaded from the releases page and then be run from your project directory:

php mozart.phar compose

Composer

To install Mozart and its dependencies, without conflicting with the dependencies of your project, it is recommended that you install Mozart as a global package, if you choose to install Mozart via Composer.

Global package

Using the global command when installing Mozart, it will be installed as a system wide package:

composer global require coenjacobs/mozart

You can then find the bin file named mozart inside your ~/.composer/vendor/bin/ directory and run it from your project directory, referencing the full path to the bin file:

~/.composer/vendor/bin/mozart compose

Development dependency of your project

You can install through Composer in the project itself, only required in development environments:

composer require coenjacobs/mozart --dev

This gives you a bin file named mozart inside your vendor/bin directory, after loading the whole package inside your project. Try running vendor/bin/mozart to verify it works.

After configuring Mozart properly, the mozart compose command does all the magic:

vendor/bin/mozart compose

Configuration

Mozart requires little configuration. All you need to do is tell it where the bundled dependencies are going to be stored and what namespace they should be put inside. This configuration needs to be done in the extra property of your composer.json file:

"extra": {
    "mozart": {
        "dep_namespace": "CoenJacobs\\TestProject\\Dependencies\\",
        "dep_directory": "/src/Dependencies/",
        "classmap_directory": "/classes/dependencies/",
        "classmap_prefix": "CJTP_",
        "packages": [
            "pimple/pimple"
        ],
        "excluded_packages": [
            "psr/container"
        ],
        "override_autoload": {
            "google/apiclient": {
                "classmap": [
                    "src/"
                ]
            }
        },
        "delete_vendor_directories": true
    }
},

The following configuration values are required:

  • dep_namespace defines the root namespace that each package will be put in. Example: Should the package we're loading be using the Pimple namespace, then the package will be put inside the CoenJacobs\\TestProject\\Dependencies\\Pimple namespace, when using the configuration example above.
  • dep_directory defines the directory the files of the package will be stored in. Note that the directory needs to correspond to the namespace being used in your autoloader and the namespace defined for the bundled packages. Best results are achieved when your projects are using the PSR-4 autoloader specification.
  • classmap_directory defines the directory files that are being autoloaded through a classmap, will be stored in. Note that this directory needs to be autoloaded by a classmap in your projects autoloader.
  • classmap_prefix defines the prefix that will be applied to all classes inside the classmap of the package you bundle. Say a class named Pimple and the defined prefix of CJTP_ will result in the class name CJTP_Pimple.

Important: Since Mozart automatically processes the full dependency tree of the packages you specify, you need to specify all these configuration options, because you can't reliably determine what kind of autoloaders are being used in the full dependency tree. A package way down the tree might suddenly use a classmap autoloader for example. Make sure you also include the namespace directory and classmap directory in your own autoloader, so they are always loaded.

The following configuration is optional:

  • delete_vendor_directories is a boolean flag to indicate if the packages' vendor directories should be deleted after being processed. default: true.
  • packages is an optional array that defines the packages to be processed by Mozart. The array requires the slugs of packages in the same format as provided in your composer.json. Mozart will automatically rewrite dependencies of these packages as well. You don't need to add dependencies of these packages to the list. If this field is absent, all packages listed under composer require will be included.
  • excluded_packages is an optional array that defines the packages to be excluded from the processing performed by Mozart. This is useful if some of the packages in the packages array define dependent packages whose namespaces you want to keep unchanged. The array requires the slugs of the packages, as in the case of the packages array.
  • override_autoload a dictionary, keyed with the package names, of autoload settings to replace those in the original packages' composer.json autoload property.

After Composer has loaded the packages as defined in your composer.json file, you can now run mozart compose and Mozart will bundle your packages according to the above configuration. It is recommended to dump the autoloader after Mozart has finished running, in case there are new classes or namespaces generated that aren't included in the autoloader yet.

Scripts

Mozart is designed to install and be forgotten about. Using Composer scripts, the Mozart script can be run as soon as Composer either installs a new package, or updates an already installed one. This ensures that the packages you want to bundle, are always bundled in the latest installed version, automatically. These scripts also offer you the possibility to script dumping the autoloader, after Mozart is finished running:

"scripts": {
    "post-install-cmd": [
        "\"vendor/bin/mozart\" compose",
        "composer dump-autoload"
    ],
    "post-update-cmd": [
        "\"vendor/bin/mozart\" compose",
        "composer dump-autoload"
    ]
}

When using Mozart through its Docker container, you can replace the "\"vendor/bin/mozart\" compose", lines with the actual commands you use to run the Docker container for your specific project. Running Mozart from inside the Docker container is really fast and shouldn't take more than a couple seconds.

Background and philosophy

Mozart is designed to bridge the gap between the WordPress ecosytem and the vast packages ecosystem of PHP as a whole. Since WordPress is such an end-user friendly focussed CMS (for good reasons), there is no place within the ecosystem where an end-user would be burdened with using a developers tool like Composer. Also, since WordPress has to run on basically any hosting infrastructure, running Composer to install packages from the administration panel (trust me, I've tried - it can be done) is a mission impossible to make it happen and compatible with every server out there.

But why make a new tool for this? There are other tools that enable you to do this, right? Yes, there are now. PHP-Scoper, for example. PHP-Scoper is a fantastic tool, that does the job right. But, PHP-Scoper wasn't available back when I started the Mozart project. Also, PHP-Scoper has a few limitations (no support for classmap autoloaders, for example) that were and are still quite common within the WordPress ecosystem. Finally, PHP-Scoper can be quite the tool to add to your development flow, while Mozart was designed to be simple to implement, specifically tailored for WordPress projects.

The key values of what's important to Mozart:

  • Must be able to be easily installable by a developer, preferably in a specific version.
  • Distribution must be done through an existing package manager or easily maintained separately.
  • Shouldn't add a whole layer of complexity to the development process, i.e. learning a whole new tool/language.

Mozart always has been and always will be geared towards solving the conflicting dependencies problem in the WordPress ecosystem, as efficiently and opinionated as possible. By being opinionated in certain ways and specifically focussed on WordPress projects, Mozart has quickly become easy to understand and implement.

Comments
  • NamespaceReplacer inserts duplicate namespace

    NamespaceReplacer inserts duplicate namespace

    I've found this behaviour since implementing the commit by costasovo for supporting dependency trees. The regex within the replace function in NamespaceReplacer.php can result in the configured mozart dep_namespace value to be inserted into namespace definitions multiple times if a file is passed to the method more than once

    Changing the regex so that only namespaces which don't already contain the configured value are matched, resolves the issue.

    e.g '/([^\?])(?<!'.addslashes($this->dep_namespace).')(' . addslashes($searchNamespace) . '[\|;])/U'

    opened by iandillon 17
  • Add a mechanism to exclude packages from processing

    Add a mechanism to exclude packages from processing

    Here we add an optional excluded_packages configuration key, which is an array of package slugs. Any package included here won't be processed by Mozart: it won't have its namepsaced changed and won't be moved from its original location. Namespace references to these packages won't be changed either.

    This is useful if there are dependent packages whose namespace shouldn't be changed, for examle psr/container. Example composer.json:

    {
        ...
        "extra": {
            "mozart": {
            ...
                "packages": [
                    "league/container"
                ],
                "excluded_packages":[
                    "psr/container"
                ]
            }
        }
    }
    

    Note that this pull request is similar in intent to the one to skip namespaces by leoloso, but in this case we are excluding whole packages, not namespaces.

    opened by Konamiman 10
  • Carbon Fields, including non-class files

    Carbon Fields, including non-class files

    HI Coen and devs.

    I'm trying to include Carbon Fields, which looks like this:

    vendor/htmlburger/carbon-fields
    ├── CONTRIBUTING.md
    ├── ISSUE_TEMPLATE.md
    ├── README.md
    ├── assets
    ├── bin
    ├── build
    ├── composer.json
    ├── config.php
    ├── core
    ├── languages
    ├── license.txt
    ├── package.json
    ├── packages
    ├── templates
    ├── webpack.config.js
    └── yarn.lock
    

    Where the autoload config is like this:

    "psr-4": {
      "Carbon_Fields\\": "core/"
    }
    

    And Mozart is only putting the files from core into src/Dependencies/Carbon_Fields:

      "dep_namespace": "MZoo\\MzMboAccess\\Dependencies\\",
      "dep_directory": "/src/Dependencies/",
      "classmap_directory": "/src/Classes/",
      "classmap_prefix": "MZMBOACCESS_",
      "packages": [
          "htmlburger/carbon-fields"
      ]
    

    I'm working with override_autoload, but may be misunderstanding how it's supposed to work:

    "override_autoload": {
        "htmlburger/carbon-fields": {
          "psr-4": {
            "Carbon_Fields\\": "core/"
          },
          "files": [
            "config.php", 
            "templates",
            "assets",
            "build"
          ]
        }
    }
    

    Still, only the contents of core are copied.

    If I set

          "psr-4": {
            "Carbon_Fields\\": "./"
          },
    

    All files are copied, but with incorrect namespaces.

    Wondering if I should just be manually including the config.php, templates, assets, build and hoping someone here has some insight into the problem.

    opened by MikeiLL 9
  • Fix all PHPStan Level 4 problems

    Fix all PHPStan Level 4 problems

     ------ ---------------------------------------------------------------------------------------------
      Line   Mover.php
     ------ ---------------------------------------------------------------------------------------------
      73     Access to an undefined property CoenJacobs\Mozart\Composer\Autoload\Autoloader::$namespace.
     ------ ---------------------------------------------------------------------------------------------
    
     ------ ---------------------------------------------------------------------------------------------------
      Line   Replace/NamespaceReplacer.php
     ------ ---------------------------------------------------------------------------------------------------
      22     Call to an undefined method CoenJacobs\Mozart\Composer\Autoload\Autoloader::getSearchNamespace().
     ------ ---------------------------------------------------------------------------------------------------
    

    These interface-things are the 2 remaining ones. Please use @phpstan.

    opened by szepeviktor 7
  • Using library nesbot/carbon results in malformed namespace definitions

    Using library nesbot/carbon results in malformed namespace definitions

    As reported by @danieliser:

    I think it may be related to another issue I mentioned to @coenjacobs on Twitter. Specifically loading the nesbot/carbon library was mucking it all up I think. It seems to be working without that lib. Specifically when we tried to parse that package:

    Namespaces got messed up, instead of My\Dependencies\Pimple\Container, we were getting Pimple\ContainerMy\Dependencies\ which is clearly wrong. It was deleting the files from vendor.

    No idea why, would love to know though.

    Related composer.json config: https://gist.github.com/danieliser/2a0af213ec608c216bddc7cc7fa76df7

    opened by coenjacobs 7
  • Does not work for dependencies following the WordPress file naming pattern

    Does not work for dependencies following the WordPress file naming pattern

    Libraries following the WordPress naming pattern (class-some-name.php) need to use the classmap autoloader. mozart treats these as old, pseudo-namespaces classes even when they are namespaced.

    opened by mundschenk-at 7
  • Generate classmap

    Generate classmap

    This PR adds creation of a classmap file from the ~~PSR-0~~ "classmap_directory" files managed by Mozart.

    Defaults to none.

    Configured in composer.json with

    "classmap_output": {
      "filename": "src/autoload_classmap.php",
      "relative_path": "/src"
    },
    

    Then used in the plugin with:

    $class_map_file = __DIR__ . '/autoload_classmap.php';
    if ( file_exists( $class_map_file ) ) {
    
    	$class_map = include $class_map_file;
    
    	if ( is_array( $class_map ) ) {
    		spl_autoload_register(
    			function ( $classname ) use ( $class_map ) {
    
    				if ( array_key_exists( $classname, $class_map ) && file_exists( $class_map[ $classname ] ) ) {
    					require_once $class_map[ $classname ];
    				}
    			}
    		);
    	}
    }
    
    opened by BrianHenryIE 6
  • Support dependency tree of packages

    Support dependency tree of packages

    ~~I've added an option--with_dependencies for the compose command. When the command runs without the option it does nothing to sub-deps and it works same as current version.~~

    When the command runs it process all installed sub-dependencies of a package (required and suggested) as if they were listed in mozart config. (commit)

    After moving all dependencies it replaces sub-dependency namespaces or classnames within parent dependency package. (commit)

    Closes #1

    opened by costasovo 6
  • PSR-0 Support?

    PSR-0 Support?

    I'm trying this out because my Braintree integration uses Composer to load the BrainTree SDK and WooCommerce is using a cut and pasted version of the BrainTree SDK and one of my users has both plugins...

    The Braintree PHP SDK uses a PSR-0 autoloader for some reason. When I run motzart they files are copied to the new dependencies dir with no change.

    Is there an undcoumented step for PSR-0, or no support? I'm going to attempt to figure this out, if I do, I will put in a PR...

    opened by Shelob9 6
  • Return one Autoloader per namespace

    Return one Autoloader per namespace

    When a composer.json's autoload key contains two namespaces, return two Autoloader objects. e.g. RubixML/Tensor

    https://github.com/RubixML/Tensor/blob/86bb628781f311684a6778744a22b283efdae58f/composer.json#L36-L39

    opened by BrianHenryIE 5
  • exclude_files

    exclude_files

    Add a config option to exclude files based on regex match.

    Problem encountered because illuminate/collections's namespace is Illuminate\Support!

    {
        "name": "illuminate/collections",
    ...
        "autoload": {
            "psr-4": {
                "Illuminate\\Support\\": ""
            },
            "files": [
                "helpers.php"
            ]
        },
    

    When I try to use both it and actual illuminate/support I get errors because Mozart is using the namespace to choose the target folder, not the package name.

    File already exists at path: src/vendor/Illuminate/Support/LICENSE.md  
    File already exists at path: src/vendor/Illuminate/Support/composer.json  
    

    So I wrote some code to exclude them but then got:

    File already exists at path: src/vendor/Illuminate/Support/helpers.php
    

    The two helpers.php are not the same. But they're not being PSR-4 auto-loaded anyway, so I excluded it and Mozart does not complain.

    Broken:

    {
      "name": "brianhenryie/mozart-illuminate-file-clash",
      "require": {
        "illuminate/support": "^8.0",
        "illuminate/collections": "^8.0"
      },
      "require-dev": {
        "coenjacobs/mozart": "dev-master"
      },
      "extra": {
        "mozart": {
          "dep_namespace": "BH\\",
          "dep_directory": "/src/vendor/",
          "classmap_directory": "/src/classes/",
          "classmap_prefix": "BH_",
          "delete_vendor_directories": false
        }
      },
      "scripts": {
        "post-install-cmd": [
          "vendor/bin/mozart compose"
        ],
        "post-update-cmd": [
          "vendor/bin/mozart compose"
        ]
      }
    }
    

    working:

    {
      "name": "brianhenryie/mozart-illuminate-file-clash",
      "require": {
        "illuminate/support": "^8.0",
        "illuminate/collections": "^8.0"
      },
      "require-dev": {
        "coenjacobs/mozart": "dev-master",
        "cweagans/composer-patches": "~1.0"
      },
      "extra": {
        "patches": {
          "coenjacobs/mozart": {
            "Exclude Files": "https://github.com/coenjacobs/mozart/pull/83.patch"
          }
        },
        "mozart": {
          "dep_namespace": "BH\\",
          "dep_directory": "/src/vendor/",
          "classmap_directory": "/src/classes/",
          "classmap_prefix": "BH_",
          "delete_vendor_directories": false,
          "exclude_files": ["/\\.md$/","/composer\\.json/","/helpers\\.php/"]
        }
      },
      "scripts": {
        "post-install-cmd": [
          "vendor/bin/mozart compose"
        ],
        "post-update-cmd": [
          "vendor/bin/mozart compose"
        ]
      }
    }
    
    opened by BrianHenryIE 4
  • prevent prepending classmap prefix multiple times

    prevent prepending classmap prefix multiple times

    On my project some weird bug happened with prepending same prefix multiple times to classmaps. I couldn't locate where is the problem, so I have prepared "dirty" fix.

    obraz

    opened by Dartui 0
  • allow to skip duplicated files

    allow to skip duplicated files

    Problem

    if you want to use two packages with same namespace (e.g. illuminate/support and illuminate/collections) which shares similar files, Mozart will throw an "File already exists" error.

    Solution

    While moving file check if it already exists. In case mentioned above it is only LICENSE.md file, so it doesn't matter from which package it will be. Also added flag to config to allow enabling this behavior (disabled by default).

    opened by Dartui 0
  • Error File already exists at path

    Error File already exists at path

    I'm trying to use this package over php-scoper, as php-scoper is rather complicated and confusing to implement, however, when I try to run vendor/bin/mozart compose I keep running into this error:

    In Filesystem.php line 406:
      File already exists at path: vendor_prefix/packages/Doctrine/Inflector/Inflector.php  
    

    I've tried to do what was suggested here, but that didn't resolve anything for me.

    This is my package.json

    {
    	"name": "cs/ms-scraper",
    	"require": {
    		"php": ">=7.4",
    		"illuminate/support": "^5.6",
    		"guzzlehttp/guzzle": "^7.3",
    		"mailjet/mailjet-apiv3-php": "^1.5",
    		"monolog/monolog": "^2.3",
    		"10quality/wp-query-builder": "^1.0",
    		"nesbot/carbon": "^2.31"
    	},
    	"require-dev": {
    		"squizlabs/php_codesniffer": "^3.5",
    		"roave/security-advisories": "dev-master",
    		"coenjacobs/mozart": "dev-master",
    		"cweagans/composer-patches": "*"
    	},
    	"config": {
    		"optimize-autoloader": true,
    		"preferred-install": "dist"
    	},
    	"minimum-stability": "dev",
    	"prefer-stable": true,
    	"scripts": {
    		"post-root-package-install": [
    			"\"vendor/bin/mozart\" compose",
    			"composer dump-autoload"
    		],
    		"post-root-package-update": [
    			"\"vendor/bin/mozart\" compose",
    			"composer dump-autoload"
    		],
    		"test": [
    			"phpcs"
    		]
    	},
    	"extra": {
    		"mozart": {
    			"dep_namespace": "MS\\Vendor\\",
    			"dep_directory": "/vendor_prefix/packages/",
    			"classmap_directory": "/vendor_prefix/classes/",
    			"classmap_prefix": "MS_",
    			"delete_vendor_directories": true
    		}
    	}
    }
    
    

    Any suggestions?

    opened by kupoback 3
  • Dependency namespace being written on every line when overriding autoloader

    Dependency namespace being written on every line when overriding autoloader

    I have a WordPress theme which uses Timber via Composer. Timber has a dependency of a version of Twig that has the following autoloader in their composer.json.

        "autoload": {
            "psr-0" : {
                "Twig_" : "lib/"
            },
            "psr-4" : {
                "Twig\\" : "src/"
            }
        },
    

    When I attempt to run vendor\bin\mozart compose, I get an error, File already exists at path: lib/Dependencies/Twig/Extension/InitRuntimeInterface.php. I understand why this error happens, because in the twig package they have the same set of files in different directories to support both psr-0 and psr-4 and mozart is trying to process it twice.

    I attempted to override this autoloader behavior in the mozart configuration, but I don't think I'm doing it right. I tried the following:

    "override_autoload": {
                    "twig/twig": {
                        "psr-0" : {
                            "Twig_" : "src/"
                        },
                        "psr-4" : {
                            "Twig\\" : "src/"
                        }
                    }
                },
    

    When compose ran, it copied my dependent namespace on every line of the processed files. I also tried having psr-0 with empty curly braces and got the same behavior. I am using mozart version 0.7.1.

    Am I going about this the wrong way?

    opened by begroff 1
  • Does not move dependencies if using a non-default vendor directory

    Does not move dependencies if using a non-default vendor directory

    If the vendor directory is set to anything other than 'vendor', mozart compose fails silently without doing anything. When integrating composer into legacy codebases it is sometimes necessary to use a non-standard vendor directory, if the usua path is already occupied. I have addressed this in #131

    opened by Flickwire 0
Releases(0.7.1)
  • 0.7.1(Feb 2, 2021)

    As @szepeviktor mentioned, the PHAR we created starting from the last release was way too big (at a whopping 14MB). This was caused because all the development dependencies were included as well. This release changes that, reducing the created PHAR to 1.3MB.

    Source code(tar.gz)
    Source code(zip)
    mozart.phar(1.23 MB)
  • 0.7.0(Feb 1, 2021)

    This release quickly follows the 0.6.0 release and is focussed on solving the problems with distribution and isolation Mozart has been facing. That's why Mozart is now available as a Docker image and a PHAR file will be attached to each release and can be downloaded from the releases page (or via Phive). All of this is to ensure that Mozart can run in isolation itself and not have potential conflicts with your projects dependencies (yes, for a package claiming to solve dependency conflicts, this is crazy meta - I know!).

    I've also put lots of attention to the installation instructions in the README, explaining how the different installations methods work and point at the pros and cons for each.

    Mozart is now supporting all supported PHP versions, which include: PHP 7.3, 7.4 and 8.0. Support for PHP 7.2 has been dropped.

    Other than the logistical part of the project, 0.7.0 is a very small release. No actual code has been changed, apart from some code standards and minor fixes. The availability of the Docker image and the building of PHAR files is a big step forward though!

    Source code(tar.gz)
    Source code(zip)
    mozart.phar(14.61 MB)
  • 0.6.0(Jan 17, 2021)

    This has been in the works for far longer than it should have. Special thanks to @BrianHenryIE as he has been so hard at work with multiple changes and debugging things for other developers, in the issues. I try to scrape every single bit of time that I can put into Mozart, but I don't know how I could do it without him. 🎉

    In this release, the highlights are:

    • Default to handle all packages required by your project: If you want all your packages required in your project, to be transformed by Mozart after installing, you can omit the packages key in the configuration and Mozart will transform all packages.
    • The autoload configuration of a package can be changed: Using the override_autoload configuration key, you can specify the autoload configuration for that package, after it is transformed by Mozart.
    • You can now exclude packages that are being loaded from one of your own dependencies: Using the excluded_packages configuration key you can disable a package from being transformed by Mozart. This is useful for packages, for example PSR-11's ContainerInterface that is a standardised class.
    • The full dependency tree of packages is now properly being transformed: This means that the full tree of dependencies is processed, no matter how deep that tree is.

    Besides the highlights, Mozart has been improved across the board. A whole lot of fixes have been merged over the past couple months, that have made the code base more solid and bug free.

    Aside: By the end of last year, I posted a long post about my thoughts about the future of Mozart: The future of Mozart - we're at a crossroad! - I've spent the first weeks of this year, thinking this through some more. Right now, I feel I have a solid understanding of the most pressing issues within our tiny ecosystem. Enough at least, to put a little roadmap together, which I'll post soon. The next release of Mozart will be all about distribution of the package, adding a Docker image and possibly other means of running the code, in addition to requiring Mozart as a package in your project. More on that soon!

    Source code(tar.gz)
    Source code(zip)
  • 0.6.0-beta-3(Jun 2, 2020)

    • Conditional logic in verifying the composer.json file is valid #49
    • Classmap target directory will include a .gitkeep file in order to persist the directory in CVS #52
    • Classmap replace is done on the full copied classmap directory structure #42

    Thank you @markjaquith and @BrianHenryIE for your contributions! 🎉

    Source code(tar.gz)
    Source code(zip)
  • 0.6.0-beta-2(May 23, 2020)

  • 0.6.0-beta-1(May 23, 2020)

    With so much going on, I feel a proper beta for this next release is in order. I'd like to run this through some rigorous testing before tagging the stable release.

    I still want to check if #42 is still required after #39 is already merged.

    Thanks a ton, @BrianHenryIE for all the help and contributions. I'll get your contributions properly attributed in the release notes once this becomes the next stable.

    Source code(tar.gz)
    Source code(zip)
  • 0.5.1(Dec 23, 2019)

  • 0.5.0(Dec 23, 2019)

    Santa came early and dropped a new release of Mozart. This release contains:

    • Thanks to @Willemijnr, I have been able to find this bug. More details in pull request #31, but the tldr is: After moving packages to the target directory, they are removed from the /vendor directory. This has been on my radar for a while to test out, but this bug proved that it was worth my while.
    • In #32 I have bumped all requirements to a more modern version. This includes PHP 7.2 because PHP 7.1 is now EOL for almost a month. My personal opinion is still that Mozart is a developers tool and developers should lead by example: Hello to a more modern PHP version! 🎉
    Source code(tar.gz)
    Source code(zip)
  • 0.4.0(Jun 27, 2019)

    Version 0.4.0 of Mozart is here. The main change that everyone will notice is that Mozart now requires PHP 7.1 and up. The reasoning behind this is documented in #26, but the tldr is:

    Mozart is a developers tool. In my humble opinion, developers should lead by example in using supported PHP versions only and have no reason to stay behind on unsupported versions.

    Further changes in this release:

    • Thanks to @kmgalanakis, we now have full Windows support, resolving an issue with the directory separator symbol. See #21 for more details.
    • Thanks to @schlessera, we're now using modern versions of the Symfony components being used. With bumping the PHP version requirement, allowed me to make these new versions the only version we're using and making the version constraint more specific (only allowing ^4 now of both symfony/console and symfony/finder packages). See #25 for more details.
    • I've fixed a bug where it would fail previously when trying to copy the same package to the new directory more than once. See #19 for more details.

    Big thank you to everyone contributing to and using Mozart, your help is very much appreciated! 🎉

    Source code(tar.gz)
    Source code(zip)
  • 0.3.0(Feb 6, 2019)

    Thanks to the hard work of @costasovo in his attempt to support rewriting the full dependency tree in #10, I have been able to tackle this issue now finally. This release contains:

    • Full dependency tree support. All dependencies (and their dependencies and so on...) are now automatically processed by Mozart. You only need to define the dependencies of your own project that you want to rewrite and the full dependency tree of those packages will be processed.
    • Smarter logic when copying classmap autoloaders. Sometimes there was weird behaviour noticeable when a package contained both classmap autoloaders and namespace autoloaders, resulting in files not being copied or ending up in the wrong directories. This release fixes that.
    Source code(tar.gz)
    Source code(zip)
  • 0.2.0(Mar 24, 2017)

    The second version of Mozart available for public testing is now available, introducing:

    • Added support for classmap autoloader prefixing. The Configuration documentation has been updated to give instructions on how to use this.
    • Regexes for detecting and replacing class names and namespaces has been improved.
    Source code(tar.gz)
    Source code(zip)
Owner
Coen Jacobs
🚀 🇳🇱
Coen Jacobs
A curated list of Awesome WordPress Theme, Plugins and Framework development Resources and WordPress Communities.

Awesome WordPress A curated list of Awesome WordPress Theme, Plugins and Framework development Resources and WordPress Communities. Inspired by bayand

Dropndot Limited 91 Dec 26, 2022
WordPress & TypeScript. Simple starter template for WordPress projects

WordPress & TypeScript. Simple starter template for WordPress projects that want to use TypeScript in combination with @wordpress/scripts

Make it WorkPress 11 Sep 27, 2022
A foundation for WordPress Plugin Development that aims to provide a clear and consistent guide for building your plugins.

WordPress Plugin Boilerplate A standardized, organized, object-oriented foundation for building high-quality WordPress Plugins. Contents The WordPress

Devin 7.2k Jan 4, 2023
A tool box of integrations for Cardano & WordPress all packaged into a neat plugin.

CardanoPress A tool box of integrations for Cardano & WordPress all packaged into a neat plugin. This plugin allows you to integrate various Cardano b

Peter Bui 38 Oct 4, 2022
This WordPress Plugin Boilerplate is meant for you to develop your own plugin on.

WordPress Plugin Boilerplate This plugin boilerplate is meant for you to develop your own plugin on. Support & collaboration Features OOP plugin core

richardev 2 May 10, 2022
📦 A zero-configuration #0CJS developer toolkit for building WordPress Gutenberg block plugins.

create-guten-block is zero configuration dev-toolkit (#0CJS) to develop WordPress Gutenberg blocks in a matter of minutes without configuring React, w

Ahmad Awais ⚡️ 3.1k Dec 23, 2022
A WordPress package for updating custom plugins and themes based on an API response from a custom update server.

WordPress Update Handler A WordPress package for updating custom plugins and themes based on an JSON REST API response from a custom update server. Ch

WP Forge 7 Oct 5, 2022
A custom update API for WordPress plugins and themes

A custom update API for WordPress plugins and themes. Intended to be used in conjunction with my plugin-update-checker library.

Yahnis Elsts 717 Dec 31, 2022
Rabbit Framework - A modern way of building WordPress plugins

Rabbit Framework - A modern way of building WordPress plugins. About Rabbit Framework is a modern framework designed to be a solid foundation for your

VeronaLabs 8 Nov 20, 2022
A WordPress eCommerce platform for developers

Hubaga A WordPress eCommerce plugin for developers. It is lightweight and simple to use. Looking for a premium for wordPress search plugin? Check out

null 23 Jul 24, 2021
A WordPress theme switcher for developers

WP Theme Switcher To help you build or preview a new theme directly on your site without affecting your visitors (they always see the default theme wh

WP Clevel 3 Oct 20, 2021
Style guide for writing consistent PHP for WordPress projects.

Inpsyde PHP Coding Standards PHP 7+ coding standards for Inpsyde WordPress projects. Installation The code styles are enforced via the popular php_cod

Inpsyde GmbH 77 Nov 14, 2022
This WP plugin will update GitHub, Bitbucket, GitLab, and Gitea hosted plugins and themes

Transition from GitHub Updater 9.x to Git Updater 10.x Due to the renaming of the plugin folders and files, after the initial update, the plugin will

Andy Fragen 3k Jan 5, 2023
Curated list that contain code, snippets or examples without libraries or external packages for developers.

Awesome WordPress Developer Tips Curated list that contain very awesome and ready code, snippets or examples without libraries or external packages ma

Daniele Scasciafratte 110 Nov 13, 2022
WordPress plugin that allows admin to force logout all users

User Login Control User Login Control is a WordPress plugin allows you to logout user(s) from their account or to see the last activity of your offlin

null 4 Sep 6, 2022
🚀 All-in-one enhancement plugin that improves WordPress & BuddyBoss integration.

=== Buddyboss Extended Add-on === Contributors: jcatama Donate link: https://www.paypal.me/jcatama Tags: buddyboss, buddypress, learndash, forums, gro

Albert Catama 1 Oct 12, 2022
EzPz Tweaks is an all-in-one WordPress plugin that helps you personalize the admin panel appearances

EzPz Tweaks is an all-in-one WordPress plugin that helps you personalize the admin panel appearances, clean your site code and remove unwanted features to increase its security and improve performance.

WP EzPz 7 Jul 24, 2022
The most powerful all in one, SEO-friendly theme for WordPress.

Help us Become a backer via Patreon. Make one time donation with PayPal. About Seven SERP Theme Seven SERP Theme is an open source WordPress theme. Wi

Seven SERP 3 Nov 19, 2021
The Pronamic WordPress Basecone plugin allows you to connect your WordPress installation to Basecone.

Pronamic WordPress Basecone The Pronamic WordPress Basecone plugin allows you to connect your WordPress installation to Basecone. Table of contents Au

Pronamic 1 Oct 19, 2021