Use composer to install the colorbox and dompurify library

https://asset-packagist.org/package/bower-asset/colorbox

Should the project's composer.json be updated to reference the library? That way just doing a composer require on the module itself would get the library and put it in the appropriate location.

Basic question: Is the library available for simple download anywhere? There is a link in the comments above, but I think it's to the colorbox git project, not the library. Found it. Feel kind of dumb. https://github.com/jackmoore/colorbox/archive/1.6.4.zip

Re #6 The project's composer.json cannot be updated to reference the library because composer only supports the repositories key for the "Top Level" or project level composer.json. If you require a package that has repository data in its composer.json, it will be ignored.

If you use composer to download the colorbox library to libraries (easily doable), it works as designed. In idea situations, vendor is not exposed to the internet at all so that is unlikely to be supported.

@NickWilde

Newb: "If you use composer to download the colorbox library to libraries (easily doable)"

*How* is it easily doable please? I can't find a way...

S

@smartin: google for "drupal asset packagist", for example here: https://drupal.stackexchange.com/questions/262203/how-to-install-with-co...

For those you use still having problems figuring out how to insert the new repository into your existing composer.json file, here is how mine looks (this is just the repository section of the composer.json file. You don't need to edit any other section of this file:

    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "package",
            "package": {
              "name": "jackmoore/colorbox",
              "version": "1.6.4",
              "type": "drupal-library",
              "dist": {
                "url": "https://github.com/jackmoore/colorbox/archive/1.6.4.zip",
                "type": "zip"
              }
            }
        }
    ],

Then from your drupal root, run command:

composer require jackmoore/colorbox

This will add the required package to the composer.json file and into the correct libraries folder.

@xamount: i think that use of https://asset-packagist.org/ is better these days as most used distros use it.

#12 worked for me. Created a patch which will add the lines in the Readme.txt file.

I didn't have luck with jackmoore, but bower seems to work:

composer require bower-asset/colorbox.

Thank you so much bwoods!

Beware to remove jackmoore/colorbox before require its bower counterpart.

composer remove jackmoore/colorbox
composer require bower-asset/colorbox:1.6.4

Bower resolves it like this, with the official repo:

EDIT: Do not use this into your composer.json (neither into composer.lock, of course).

        {
            "name": "bower-asset/colorbox",
            "version": "1.6.4",
            "source": {
                "type": "git",
                "url": "git@github.com:jackmoore/colorbox.git",
                "reference": "bac78120c6ca9e63370cc317ab6f400129cd6608"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/jackmoore/colorbox/zipball/bac78120c6ca9e63370cc317ab6f400129cd6608",
                "reference": "bac78120c6ca9e63370cc317ab6f400129cd6608"
            },
            "require": {
                "bower-asset/jquery": ">=1.3.2"
            },
            "type": "bower-asset"
        },

More info about bower: https://www.drupal.org/docs/develop/using-composer/using-composer-to-ins...

#12 worked perfectly for me too. Thank you!

#12 worked for me. Many thanks.

hello,

using Drupal 9.2, I have a question about #12

I wanted to use the merge plugin, but somehow it doesn't work and that "path repository" is to be used instead.

now, seeing that a particular version is set in #12, how do I make sure the library is automatically updated if colorbox module decides to use a new version for the library?

@manarak : I've got the same problem. I think colorbox should apply the same approach as webform, see : https://www.drupal.org/docs/8/modules/webform/webform-frequently-asked-q...

Reopening to let the maintainer consider using a "composer.libraries.json" file with the "require" composer statement in order to be able to user the composer "merge" plugin to automatically install the library, following a similar path to what the webform module has already done.

Revised IS to better encapsulate the problem.

Yet another pathway towards a solution of this would be to follow what the CKEditor 4 ecosystem has done (see https://www.drupal.org/project/ckeditor_libraries_group ) with Shimmy ( https://www.drupal.org/project/shimmy ). However, Shimmy hasn't had much uptick in creating additional shim projects for contrib: https://packagist.org/packages/drupal-shimmy/

I like the solid approach from webform module.

Basically, require the composer-merge-plugin

composer require wikimedia/composer-merge-plugin

Then, add the following lines to your project's composer.json inside the "extras" section:

        "merge-plugin": {
            "include": [
                "web/modules/contrib/webform/composer.libraries.json"
            ]
        },

Finally, add the Webform module dependency:

composer require drupal/webform

This will add the module, then also install all the 3rd party library dependencies as defined in webform/composer.libraries.json and put them into the Drupal libraries folder.

To adapt this approach for colorbox, we need a patch where the contents of the "composer.libraries.json" file could be very similar to code snippets from #3and #12 above.

For documentation updates, see https://www.drupal.org/docs/8/modules/webform/webform-frequently-asked-q... an example of how install instructions could be written.

I've asked the maintainer to check in on this issue and help provide direction. Paul mentioned he was unavailable this week, but to remind him next week on Slack to check in on this issue.

I'm in favor of the approach in #24 suggested by @jwilson3 (and earlier by @yonailo). If we can have a composer.libraries.json file similar to the webform approach, that includes both the colorbox and DOMPurify libraries, we can provide instructions in the README on how to use the composer merge plugin to install the libraries.

Bonus: if there is any way to only include the target javascript files from the respective libraries, and exclude the source files, that would be truly ideal!

If somebody would like to create a patch using the composer merge/composer.libraries.json approach, I will gladly review.

While Webform supports the composer.libraries.json, it also supports methods that don't require the wikimedia/composer-merge-plugin. Support for wikimedia/composer-merge-plugin was removed from core in #2912387: Stop using wikimedia/composer-merge-plugin. The same reasons for not including it in core apply to contrib, but the biggest reason to avoid or rely on wikimedia/composer-merge-plugin is that it isn't supported in the Composer build step on a number of popular Drupal hosts including https://pantheon.io/docs/guides/integrated-composer#issues-using-wikimed... and https://support-acquia.force.com/s/article/360035202373-Upgrading-from-B...

As far as the asset-packagist approach, Ryan Szrama recently wrote about why they replaced asset-packagist with custom page repositories in https://ryanszrama.com/blog/04-18-2022/replace-asset-packagist-custom-pa....

IMHO, initial installs with CDN dependencies that point users towards updating the project composer.json with custom package repositories and dependencies is the way to go. One big advantage of this approach is you can include the licensing. This allows users to run composer license and get a report of all licenses used in a site project. This is often a requirement for larger organizations concerned about licensing compliance. Adding the license is as simple as...

    "repositories": [
        {
            "type": "package",
            "package": {
              "name": "jackmoore/colorbox",
              "version": "1.6.4",
              "type": "drupal-library",
              "license":"MIT",
              "dist": {
                "url": "https://github.com/jackmoore/colorbox/archive/1.6.4.zip",
                "type": "zip"
              }
            }
        }
    ],

If you are interested in simplifying the process of adding the dependencies to the composer.json, take a look at how Webform handles this by using CDN versions on the initially install and recommending users localize these dependencies with drush webform:composer:update. With #3266007: Include licensing information in drupal-libraries, this process now adds the licenses of the Webform front end dependencies.

Because this project already has support for adding the required library with drush colorbox-plugin in https://git.drupalcode.org/project/colorbox/-/blob/8.x-1.x/drush/colorbo..., it would be relatively easy to add support for something similar to drush webform:composer:update.

#29++ for covering more bases, it sounds like a good approach.

I wasn't even aware of the other method to update the project composer.json from webform directly via drush or the lack of support for composer-merge-plugin on Pantheon/Acquia — we use it on both and have seen no issues (but we also do not use Pantheon composer upstream, we use the Circleci build process and Acquia Pipelines CI).

IMHO, initial installs with CDN dependencies that point users towards updating the project composer.json with custom package repositories and dependencies is the way to go.

There is one important point worth mentioning: When you define custom package repositories in your project composer.json, you assume responsibility for keeping the 3rd party library versions manually up-to-date and compatible with the Drupal module. The main promise of the wikimedia/composer-merge-plugin and composer.libraries.json is that the compatible, up-to-date and secure version is maintained in code by the Drupal contrib module provider. I appreciate the reduced/centralized maintenance effort as opposed to a distributed effort being pushed onto each website builder, and the "performance and complexity penalty" (mentioned in #2912387: Stop using wikimedia/composer-merge-plugin) of using the plugin should be evaluated by each person.

Sidenote: I wonder if the webform drush command can update existing composer.json files eg if a 3rd party library URL changes, version is updated, or is removed entirely, or does it only work for initial setup?

Support for wikimedia/composer-merge-plugin was removed from core

Just for the record: the composer-merge-plugin was removed from drupal/drupal as it turned out to be a mistake to use it to include drupal/core in a project. It was realized that including drupal/core as requirement was needed to allow your project to update core. So, as that was the only thing it was used for, there was no more need to have it in your project.

The no longer using it for core is different from removing support for it!

Since we are managing our libraries with composer...
and are using Asset Packagist for other modules already and #13 also proposes this solution:

I made a Proof of Concept patch that changes the capitalisation of the libraries dompurify folder to lowercase.

Then the install with composer is:

Add the following to your project composer.json in the "repositories" section.

        "assets": {
            "type": "composer",
            "url": "https://asset-packagist.org"
        },

Make sure you have required the oomphinc/composer-installers-extender package.

Add the following to your project composer.json in the "extra" section.

         "installer-types": [
            "bower-asset",
            "npm-asset"
        ],
        "installer-paths": {
            "docroot/libraries/{$name}": [
                "type:bower-asset",
                "type:npm-asset"
            ]
        }

then:

composer require 'drupal/colorbox:^1.10'
composer require bower-asset/colorbox
composer require npm-asset/dompurify

will put them in the proper path..

The patch does not takle the drush installation of the libraries...
it is just a proof of concept so there is still work to be done..

I use it together with "cweagans/composer-patches" in my composer.json so already now an option for people managing there libs with composer...

looked further into the drush install of dompurify and added the path correction here also...

since the path of the dompurify lib changes it might be something for a 2.x version together with D10 compatibilty stuff so people know they have to move the lib if installed to the old directory manually or with drush.

changed the version to 2.0.x-dev as suggested in #33 since my changes to the capitalisation of the dompurify library path wold break 1.x installations..

Seems to be fixed: https://www.drupal.org/project/colorbox/issues/3286579

The commit in 2.0.x: https://git.drupalcode.org/project/colorbox/-/commit/0b580c279f499a10840...

@damien yes my patch got included in that issue...

There maybe should be documentation on how to install the libs with composer ...

#32 is a possible solution but you could other sources for the libs there was a lot of discussion about the way to go

updated the issue to documentation

So a quick win for me was to simply rename the folder to 'dompurify'.

#39 worked for me also. Thanks.

Hi

#39 works for me to on D9.4.8:
mv web/libraries/DOMPurify/ web/libraries/dompurify

thanks

may I ask for some clarification, #31 , #32

currently I have this in my composer.json

    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
	    "type": "composer",
	    "url": "https://asset-packagist.org"
        },
        {
            "type": "package",
            "package": {
              "name": "jackmoore/colorbox",
              "version": "1.6.4",
              "type": "drupal-library",
              "dist": {
                "url": "https://github.com/jackmoore/colorbox/archive/1.6.4.zip",
                "type": "zip"
              }
            }
        },
...
    "require": {
...
        "jackmoore/colorbox": "^1.6",
        "oomphinc/composer-installers-extender": "^2.0",
        "wikimedia/composer-merge-plugin": "^2.0",
        "woothemes/flexslider": "^2.0"
    },
...
        "merge-plugin": {
            "include": [
                "web/modules/contrib/webform/composer.libraries.json",
                "web/modules/contrib/media_directories/composer.libraries.json",
                "web/modules/contrib/sidr/composer.libraries.json"
            ]
        }

I'm unsure of which steps I should take to stop using the merge plugin ?

Not sure what kind of clarification you need for #31. It is saying there is no need to replace it. As you don't mention your objectives for removing it, hard to tell what to do. Disagree with what it is currently doing, no idea what it means for Composer 2.

Currently, only a small part of the functionality is in use, giving up the most important part of dependency management. But, with the decision to use it, you have given away control.

#43
thank you.
I'm just trying to remain on the "main track" on how composer Drupal is done to avoid being cornered again.

I have read in multiple instances on this site that Drupal libraries shouldn't be installed via merge plugin and merge plugin should be removed.
So I was looking for instructions on how to replace the merge plugin with ... I don't even know what it should be replaced with. "path repositories" ?
https://www.drupal.org/node/3069730
https://www.drupal.org/project/drupal/issues/2912387

I'm just afraid that with some future update it will stop working.

The issues you are pointing to are removing it for including drupal/core, actually its dependencies, in your project. Absolutely agree with that. Having drupal/core a requirement in your project is much preferred. It is different from what it is doing now. Which is essentially maintaining /libraries.

Your current use is to work around limitations in Composer while insisting on the ways Drupal dealt with certain things. Giving time they will come closer together and eventually these kind of solutions much more simplified.

There is no need to be afraid of future updates, they'll improve the current solutions, not remove them. At least when Composer is concerned.

I discussed with Webbeh and kreynen in Maintainers Slack thread.

To summarize comments and takeaways up to this point, the proposal here is more than just a docs change.

We should proceed with a multi-faceted strategy that is flexible but opinionated in a way that makes things easy for site builders out-of-the-box, and builds on techniques used in Contrib.

1. Colorbox should offer an ideal (low-code) composer-based dependencies:

Colorbox module provides a composer.libraries.json, just like Webform does. This allows the module to provide a recommended version of upstream dependencies under source control. Site Builders can choose to then use the Wikimedia Composer Merge Plugin to include the file in their main project composer.json, or proceed with one of the other two methods. If this method is chosen, future Colorbox module updates will keep parity with the recommended library versions with very little additional work from Site Builders. The merge plugin being removed from core has no bearing on the validity and ease-of-use of this ideal approach.

2. Colorbox should also offer a non-composer way to install the dependencies

Colorbox module provides a drush script to download dependencies, just like Webform does.

3. Site builders can ignore #1 or #2, and use a manual composer-based approach of their choice

3.1 Site Builder may manually add the Colorbox library dependencies to their main project composer.json file "repositories" section. The initial setup could even be via copy/pasta from option #1's composer.libraries.json provided by the Colorbox module.

3.2 Alternatively, Site Builders could opt to use Asset Packagist in their main project composer.json (as opposed to the "repositories" approach). Asset Packagist is not recommended for several reasons that are out of scope of discussion bikeshedding in this context.

Ultimately option 3 (manual composer) is considered least desirable because Site Builders or Release Managers assume responsibility for manually keeping dependency version parity with the recommended library versions documented by the Colorbox Drupal module; read: "more work and cognitive load".

We've excluded drupal-shimmy as an option here though it was mentioned above by Webbeh, because it doesn't have widespread adoption. This approach, or any other approach that emerges in the community to solve 3rd party dependencies could be considered in the future. Follow #2873160: Implement core management of 3rd-party FE libraries.

Next steps:

Write a patch that adds:

• colorbox.libraries.json with module dependencies (several previous comments have examples of what the file might look like, also taking inspiration from webform module).
• drush commands to download and install dependencies. (taking inspiration from webform module)
• Necessary README & docs updates for getting started with merge plugin approach or drush approach.

FYI this repository definition worked for DOMPurify:

        "cure53/dompurify": {
            "type": "package",
            "package": {
                "name": "cure53/dompurify",
                "version": "3.0.3",
                "type": "drupal-library",
                "dist": {
                    "url": "https://github.com/cure53/dompurify/archive/3.0.3.zip",
                    "type": "zip"
                }
            }
        },

If it helps, I think the documentation on the anchor_link project page is well written. It explains how to do this with wikimedia/composer-merge-plugin in composer or in other ways. This is an old ticket and, at some point, that plugin was not usable (maybe during one of the Drupal major release transitions) but it is working very well now. However, right now, with Drupal 10, I am using the composer.libraries.json approach for both Anchor Link 3.0.0-alpha1 and Webform 6.2.2.

Something else that may have be causing confusion is the issue mentioned in #41. The Colorbox documentation shown on the Status Report and the Project page is subtly incorrect. On case-sensitive operating systems like Linux, "libraries/DOMPurify/dist/purify.min.js" is going to fail because the module is actually looking for "libraries/dompurify/dist/purify.min.js". So, yes, that is an unrelated problem but it could be making things more difficult.

+1

If it helps, here is how I installed DOMPurify with composer :

composer config repositories.assets composer https://asset-packagist.org
composer config --unset repositories.0
composer config repositories.drupal composer https://packages.drupal.org/8
composer config --json extra.installer-types '["npm-asset", "bower-asset"]'
composer config --json extra.installer-paths.web\/libraries\/dompurify '["npm-asset/dompurify"]'
composer config --unset extra.installer-paths.web\/libraries\/\{\$name\}
composer config --json extra.installer-paths.web\/libraries\/\{\$name\} '["type:drupal-library", "type:bower-asset", "type:npm-asset"]'
composer require npm-asset/dompurify
composer require bower-asset/colorbox