Create a mirror for external library dependencies for composer support

Thanks @pameeela for introducing this.

Happy to help out with this, if maintainers agree to proceed with this. Here is what we've done in other places like Fullcallendar → or Klaro → :

• Create a general project on d.o as a mirror of the remote library
• Add a composer.json to that repository, set the name to drupal/NAMEOFLIB and set the type to drupal-library, also add the installer-name in the extra section to the name of the directory into which this library needs to be installed
• Push that code and create a release, ideally with the same version number as the referencing upstream library

The packaging system from d.o will publish that project to Packagist and you can now add drupal/NAMEOFLIB to require section of the composer.json of this project. From now on, the library will be installed automatically without the user having to do anything manually.

Changing tag to target since this is a pretty last-minute request and is not trivial.

Would it be easier to add a composer.libraries file?

@smustgrave it won't help. The problem is that composer can't load the required library without the declaration of an extra repository. And that needs to be done manually in the root composer.json file, i.e. that's manual work and therefore not a solution for Drupal CMS.

As composer already knows about the repository of packagist.org, we can easily make the libraries available there and every composer can require them without any extra or manual setup. In addition to that, this approach also solves the need that the libraries then get installed in the right directory as well, i.e. /web/libraries. Also without any extra configuration.

Gotcha, sure I'm fine with the idea.

Happy New Year everybody in here. I've now managed to set-up die mirror of the javascript library, you can find that here: https://www.drupal.org/project/nouislider_js →

I've tagged a 15.8.1 release which is the equivalent of the currently latest release in the original repository.

Next step for BEF should now be to add "drupal/nouislider_js": "^15.8", to its composer.json dependencies and then, users don't have to bother about it any longer. That would also be good for Drupal CMS, so I don't know if a new tagged release in time for the forthcoming release date is feasible.

Please let me know if I should do anything else to move this forward.

darren oh → made their first commit to this issue’s fork.

This is awesome! I'll do a release for it now.

Located duplicate project:

https://www.drupal.org/project/nouislider →

Posted issue to reference as "Replaced by" as the newer one is up to date (older is 15.5.1, new is 15.8.1 and I assume has mechanism for staying up to date?) and includes the correct composer.json file, and has all of the library files instead of just the min ones.
📌 Set "Replaced by" to noUiSlider JS Active

@elc That other module is not really a duplicate as it follows a different approach. The other one is a module that provides a library that other modules can attach to pages.

The new project is not a module, it's a Drupal library which gets installed by composer in the web/libraries folder just like other libraries do.

has mechanism for staying up to date

That's a manual process.

Automatically closed - issue fixed for 2 weeks with no activity.

Hello, what is the reason to make noUISlider a hard dependency in composer?
Couldn't we make it a soft dependency, or use the npm-asset method that a lot of modules are now adopting?
https://www.drupal.org/docs/develop/using-composer/manage-dependencies#t... →

A soft dependency would mean Drupal CMS is not automatically updated if the BEF module changes.