Manage Leaflet library dependency with Composer & Asset Packagist

I've recently used http://asset-packagist.org/ for a project to pull in the dropzonejs library with some good success. You need some specific config in your root JSON file though but it is pretty easy to set up.

The Thunder project uses this as well https://github.com/BurdaMagazinOrg/thunder-project/pull/5/files and #2843288: Make use of http://asset-packagist.org/ for fetching libraries

Removing redundant issue tags and version prefix on the title.

@itamair lots of trailing whitespaces in your patch (visible when reviewing with Dreditor).

If you're looking to replace the backticks you can just indent all code lines 4 spaces. If the code is supposed to be a sub-element of a list element, then you need to indent 8 spaces. To simplify all this, you could convert your numbered lists to headings instead, kind of like what we've done here:

https://github.com/BluesparkLabs/gulp-frontend-tasks/blob/master/README.md

But, to clarify, I'm not talking about the backticks specifically when I refer to the trailing whitespace.

+++ b/README.md
@@ -18,8 +18,52 @@ It is done simply running the following command from your project package root
+2. __Require/Add the Leaflet JS library via Composer:__  ¶
+In order to do this, it is requested before to add the proper ¶
+   Leaflet JS library repository to your main composer.json file. ¶
+   It will be sited into the /Library folder. ¶
+   ¶
...
+   ¶
...
+  * Verify that the proper library destination folder is ¶
+  defined under "installer-paths" index in you (main/root) composer.json, ¶
...
+  From your project package root (at the main composer.json level) run:  ¶
+  __$ composer require leaflet/leaflet:~1.0__  ¶
...
-2. Enable the module to be able to use the configurable __Leaflet Map as 
+3. Enable the module to be able to use the configurable __Leaflet Map as ¶

These are all the lines with trailing whitespace.

Patch in #9 no longer applies. Here is a re-roll with some grammar and markdown formatting fixes for the README.

Added link to official documentation on using composer to manage drupal site dependencies.

Hrm. After reading the core issue #2873160, it looks like some best practices are emerging around using Asset Packagist.

See Comment #41 from sun here, with examples of how this is being done in another module #2873160-41: Implement core management of 3rd-party FE libraries

+  "repositories": [
+    {
+      "type": "composer",
+      "url": "https://asset-packagist.org"
+    }
+  ],
+  "require": {
+    "bower-asset/leaflet": "^1.0.3"
+  }

And

/**
  * Implements hook_libraries_info().
 */
function photoswipe_libraries_info() {
  $libraries['photoswipe'] = array(
    'name' => 'Photoswipe',
    'vendor url' => 'https://github.com/dimsemenov/PhotoSwipe',
    'download url' => 'https://github.com/dimsemenov/PhotoSwipe/archive/master.zip',
    'version arguments' => array(
      'file' => 'dist/photoswipe.min.js',
      'pattern' => '/v([\d.]+)/', // PhotoSwipe - v4.1.1 - 2015-12-24
      'lines' => 1,
      'cols' => 30,
    ),
  );
  return $libraries;
}

Maybe we should give that a try here?

Here is a patch that adopts the Asset Packagist methodology for managing the 3rd party Leaflet js package, which is emerging as a new standard best practice in the community.

The required code changes are minimal and mostly this is an overhaul of the README. I didn't bother doing an interdiff this time.

I looked into documenting an installation method without Composer and thereby adding the hook_libraries_info block mentioned in the previous comment, but this turned out to be way too complicated because the Leaflet Drupal module depends on Geofield, which itself uses composer to install the required GeoPHP 3rd party vendor library. I would say this module is now tied to Composer for installation — not necessarily a bad thing!

@itamair Before you decide to commit this, I've taken some of the instructions from this patch in the README.md and copied them and cleaned them up in the official Drupal.org documentation here:

https://www.drupal.org/docs/develop/using-composer/using-composer-to-man...

And here:

https://www.drupal.org/docs/develop/using-composer/managing-dependencies...

I also mentioned this change on #2873160-50: Implement core management of 3rd-party FE libraries.

Assuming this change doesn't create some push-back or get removed by someone, we could probably trim down the README to just reference that documentation before committing the change.

Cheers.

Would it be too much overhead to leave the current embedded leaflet library,
but introduce a new one which uses the new packagist workflow?

So there is still a fallback and there is time to migrate.
You could throw a notice at the Statuspage or whereever to signal Users that there is a new workflow in town,
and currently, the internal leaflet.js is used, but shouldnt and in the future will be deprecated, like 8.x-2.x

All libraries are gpl-compatible therefore we could add them to code like drupal core does it.

But I also do not think cdn or asset-packagist is a good way.

This patch use the hook_library_info_alter to allow the user, to managed the dependencies via composer.

Btw. with a non-cdn-version of geoman I do not have a problem with #1988968: Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS.

A totally rewrite version:

• Since leaflet_markercluster submodule just handle the JS library initialization, I give it a merge to its parent leaflet.libraries.yml
• Remove all locally vendored JS libraries, in order to avoid any Drupal.org related licensing issue
• Update JS libraries search path into /libraries/*, so assuming install by using composer + https://asset-packagist.org
• Update README.md for how to install corresponding JS libraries

https://git.drupalcode.org/project/leaflet/-/merge_requests/5 contain all of my recent patches for leaflet all-together, with screenshot as below:

@itamair to keep it simple please kindly review https://git.drupalcode.org/project/leaflet/-/merge_requests/7, which is the foundation for all follow up MR. Most likely about remove embed libraries and update in documentation.

Benefit for installing libraries with composer: https://www.drupal.org/project/leaflet/issues/2942651#comment-14307721

Once this land we could review other MR together in detail ;-)