PHPackages imarc/opus - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. imarc/opus ActiveComposer-plugin[Utility & Helpers](/categories/utility) imarc/opus ========== Multi-framework asset and module packaging for composer 2.0(1y ago)1112.1k↓23.7%1[2 issues](https://github.com/imarc/opus/issues)3MITPHPPHP ^7.2|^8.0 Since Apr 20Pushed 1y ago6 watchersCompare [ Source](https://github.com/imarc/opus)[ Packagist](https://packagist.org/packages/imarc/opus)[ RSS](/packages/imarc-opus/feed)WikiDiscussions master Synced 1mo ago READMEChangelogDependencies (5)Versions (19)Used By (3) Opus ==== [](#opus) What Does it Do? ---------------- [](#what-does-it-do) Opus copies files and directories from composer packages into your project folder. These files can be anything from CSS/JS assets, all the way to plugin code for bootstrapping. How Does it Work? ----------------- [](#how-does-it-work) Packages provide installation maps for supporting frameworks which tell Opus which files or directories to copy from the source package and where to copy them relative to the project root. Why Do I Need It? ----------------- [](#why-do-i-need-it) Opus allows for framework modules or asset libraries to be bundled together. For example, if you have a framework which allows for plugins to be installed via the copying of bootstrapping files, these can be copied automatically for the user. This is particularly useful if the imported files can be customized or modified since Opus will ensure the integrity of your changes, however, it can also be used for assets which do not change except for upstream versions such as JS libraries or CSS. Enabling Opus in Your Project's `composer.json` File ---------------------------------------------------- [](#enabling-opus-in-your-projects-composerjson-file) *NOTE: Opus will use the `name` property in the `composer.json` to determine which installation map to use from supporting packages.* In order to enable opus, you will want to require it, and set the `extra.opus.enabled` parameter to `true`: ``` "require": { "imarc/opus": "*" }, "extra": { "opus": { "enabled": true } } ``` Specifying Installation Map in Packages --------------------------------------- [](#specifying-installation-map-in-packages) Packages can support you framework by creating an installation map which is keyed by the project name. If your project is based on or is using an upstream framework but happens to have a different `name` property in the `composer.json` you can specify the framework as follows: ``` "extra": { "opus": { "options": { "framework": "" } } } ``` *NOTE: This only has to be done if the `name` in your project's `composer.json` does not match the supported framework.* Opus Packages ------------- [](#opus-packages) There are two types of Opus packages: 1. Standard Packages 2. Integration Package ### Standard Packages [](#standard-packages) A standard package is a regular composer package which has been configured to support one or more projects or frameworks by providing one or more installation maps keyed by their name. It has the following information added to the `composer.json`: ``` "type": "opus-package", "extra": { "opus": { "": { "": "", ... }, ... } } ``` When being installed or upgraded, Opus will look at the project's `name` or `extra.opus.options.framework` if the package has a matching installation map in the `extra.opus`using the name as the key. If a matching key is found, Opus will iterate over each property using the `` key to identify a file or folder location in the package and copy it to the path referenced by the `` value in supporting project. A single package can support multiple frameworks by adding multiple keyed objects to the `extra.opus` object: ``` "type": "opus-package", "extra": { "opus": { "SomeVendor/CMS": { "js/jquery.listview.js": "public/assets/lib/", "css/listview.css": "public/assets/styles/views" }, "Acme/Framework": { "js/jquery.listview.js": "docroot/js/", "css/listview.css": "docroot/css" } } } ``` ### Integration Packages [](#integration-packages) Integration packages are a bit like meta packages in composer, although they can also provide some files themselves. Principally, an integration package is used in the following circumstances: 1. When a number of third-party packages and/or package assets can or should be combined to provide a single installable feature. 2. When existing third-party packages do not support Opus directly. In short, integration packages allow you to provide installation maps for one or more packages which do not provide them in their own `composer.json` or where their existing installation map is needs to be overloaded. An integration package uses the same format as a standard package, with an additional nested object keyed by the third-party package name: ``` "type": "opus-package", "require": { "thirdparty/package": "~1.0" }, "extra": { "opus": { "Acme/Framework": { "thirdparty/package": { "css/listview.css": "docroot/css" }, } } } ``` Schema ------ [](#schema) ### Framework/Project/Root Package [](#frameworkprojectroot-package) ``` "name": "", // Used to identify package installation maps "extra": { "opus": { "enabled": true|false, // Enable/disable Opus altogether "options": { "framework": "", // Override package name to specify a framework "external-mapping": true|false // Enable/Disable external integration packages "integrity": "high|medium|low" // Medium is default (see integrity section below) } } } ``` ### Package with Built-In Opus Support [](#package-with-built-in-opus-support) ``` "type": "opus-package", "extra": { "opus": { "": { // Installation map keyed by the framework "": "", // Source / destination for this package ... }, ... // Additional supported frameworks and mappings } } ``` ### Integration Package [](#integration-package) ``` "type": "opus-package", "require": { "package": "version" // Third-party integrated package }, "extra": { "opus": { "": { // Installation map keyed by the framework "": "", // Source / destination for this package "": { // Installation map for third-party package "": "", // Source / destination for third-party ... }, ... }, ... // Additional supported frameworks and mappings } } ``` Project Integrity ----------------- [](#project-integrity) Because Opus copies files out of your vendor directory and into your project, there are some checks and balances in place which seek to ensure the integrity of your code. Let's go through some of the basics here. ### Installation Integrity [](#installation-integrity) During installation operations Opus will raise a conflict in the event a file it is attempting to copy already exists. This conflict can be responded to directly by the user and will prompt as to whether or not the file should be overwritten or kept. Additionally, it is possible to quickly view the difference between the files before making a decision. ### Update Integrity [](#update-integrity) The completion of an installation writes some meta information about the current state of files copied by Opus to an `opus.map` file in the root directory of your project. This file is then consulted for information regarding any files that may be overwritten during future updates. Unlike installation, however, because it is expected that files will exist, and because various projects might have different needs, the integrity is configurable. As noted above, you can specify an `"integrity"` option on your project's Opus options with a value of `high`, `medium`, or `low`: ``` "name": "", "extra": { "opus": { "options": { "integrity": "medium" } } } ``` #### Medium Integrity (Default) [](#medium-integrity-default) Medium project integrity follows a few basic rules: - If no file already exists, the new file is copied and its checksum is stored in the map. - If no non-whitespace differences exist between the existing file and copying file, the new file is copied and the new file checksum is stored in the map. - If differences do exist, the new file checksum is compared to the old checksum to determine if it has changed in the package itself, if not, no action is taken. - If it has changed, the checksum in the map is compared to the checksum of the current file to see if it has changed on disk, if not, the new file is copied and the checksum is updated. - If the checksum is different (indicating the developer edited the file), the user is presented with conflict resolution options (overwrite, keep, diff) Medium integrity provides a simple methodology whereby files which are copied and never changed by a developer get automatically updated with a package. However, if a developer customizes a file a future update will not simply wipe out their changes but instead provide them options as well as the ability to see the differences. #### High Integrity [](#high-integrity) High integrity is for the paranoid developer who does not want updates to override anything without their notification. As such, any conflict results in presenting the developer with conflict resolution options. Note that this can be extremely tedious for packages which may copy a lot of files, and is generally only preferable if you are seriously concerned with the validity of changes made in upstream packages. #### Low Integrity [](#low-integrity) Low integrity, similar to high integrity, makes a simple decision. Any conflicting file will be overwritten by the updated version. If you are only using packages which do not require any customization or changes to the copied files, this is probably the most useful setting. However, you should be aware that sometimes non-code related files copied by packages have important things to say. For example, if a package copies over a configuration file which you then have to modify in some way, a low setting means that on future updates your configuration file will be overwritten with the default. Addendum and Supporting Frameworks ---------------------------------- [](#addendum-and-supporting-frameworks) We encourage framework and library developers to begin providing Opus support in their frameworks, web apps, libraries, or asset packages. If you are a framework maintainer and plan to include Opus, please open an issue on this project and we'll add your namespace(s) and links to the list: - iMarc Application Base and Sitemanager \[`imarc/app-base`\]: - inKWell 3.0 \[`inkwell/framework`\]: - inKWell 2.0 \[`dotink/inkwell-2.0`\]: ### Health Score 45 — FairBetter than 93% of packages Maintenance41 Moderate activity, may be stable Popularity31 Limited adoption so far Community18 Small or concentrated contributor base Maturity77 Established project with proven stability Bus Factor1 Top contributor holds 94.7% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~252 days Recently: every ~218 days Total 17 Last Release 430d ago Major Versions 1.5.0 → 2.0-beta2023-11-11 PHP version history (3 changes)1.0PHP >=5.3.0 2.0-betaPHP >=7.4.0 2.0PHP ^7.2|^8.0 ### Community Maintainers ![](https://www.gravatar.com/avatar/4ab2b91daf2aa6e4c7f98f785a3135daa3e9998bd7021d89df05a374e28ecde5?d=identicon)[mattsah](/maintainers/mattsah) ![](https://www.gravatar.com/avatar/00725533df5fd021ac93639028725bf46bef78f6d924618a987b9bfd5c32c3eb?d=identicon)[jeffturcotte](/maintainers/jeffturcotte) --- Top Contributors [![mattsah](https://avatars.githubusercontent.com/u/586346?v=4)](https://github.com/mattsah "mattsah (36 commits)")[![jeffturcotte](https://avatars.githubusercontent.com/u/65089?v=4)](https://github.com/jeffturcotte "jeffturcotte (2 commits)") --- Tags package management ### Code Quality TestsPHPUnit Static AnalysisPHPStan Type Coverage Yes ### Embed Badge ![Health badge](/badges/imarc-opus/health.svg) ``` [![Health](https://phpackages.com/badges/imarc-opus/health.svg)](https://phpackages.com/packages/imarc-opus) ``` ### Alternatives [vaimo/composer-patches Applies a patch from a local or remote file to any package that is part of a given composer project. Patches can be defined both on project and on package level. Optional support for patch versioning, sequencing, custom patch applier configuration and patch command for testing/troubleshooting added patches. 2994.3M16](/packages/vaimo-composer-patches)[mglaman/composer-drupal-lenient 1317.4M15](/packages/mglaman-composer-drupal-lenient)[drupal/core-composer-scaffold A flexible Composer project scaffold builder. 5341.9M446](/packages/drupal-core-composer-scaffold)[drupal/core-project-message Adds a message after Composer installation. 2122.6M172](/packages/drupal-core-project-message)[olvlvl/composer-attribute-collector A convenient and near zero-cost way to retrieve targets of PHP 8 attributes 184108.8k8](/packages/olvlvl-composer-attribute-collector)[lullabot/drainpipe An automated build tool to allow projects to have a set standardized operations scripts. 41716.4k2](/packages/lullabot-drainpipe) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)