Document defining a custom package instead of asset-packagist

With the recent outage of asset-packagist, we should ensure people have alternatives that don't leave them vulnerable to outages or malicious takeovers of something as critical as that. In my projects, I'm converting away from asset-packagist to defining custom packages and copying only the necessary files into my docroot.

For Select2, this means adding the following repository to my composer.json's repositories array:
 

        {
            "type": "package",
            "package": {
                "name": "select2/select2",
                "version": "4.1.0-rc.0",
                "type": "drupal-library",
                "dist": {
                    "type": "zip",
                    "url": "https://github.com/select2/select2/archive/refs/tags/4.1.0-rc.0.zip"
                }
            }
        }

Then, rather than requiring npm-asset/select2, I revert to requiring select2/select2.

Next, making use of Oomph's oomphinc/composer-installers-extender, I instruct Composer to unzip the library outside of the docroot by adding the following to my installer-paths array:

        "installer-paths": {
            "libraries/{$name}": [
                "furf/jquery-ui-touch-punch",
                "select2/select2"
            ]
        }

Finally, by making use of Drupal's drupal/core-composer-scaffold package, I copy only the files I need for Select2 to work into my docroot:

        "drupal-scaffold": {
            "locations": {
                "web-root": "./web"
            },
            "overwrite": true,
            "file-mapping": {
                "[web-root]/libraries/select2/dist/js/select2.min.js": "libraries/select2/dist/js/select2.min.js",
                "[web-root]/libraries/select2/dist/css/select2.min.css": "libraries/select2/dist/css/select2.min.css"
            }
        },

Obviously this will need to be adjusted by the developer based on how they're already using the Drupal scaffold. The only potential drawback I can see if folks may have conflicting levels of dependency on this package (i.e. normal require vs. require-dev).

If folks don't care about copying only what's required (or can't due to a conflicting scaffold dependency), they could cut out the last step by just installing the libraries directly into the docroot's libraries folder.

Hope this helps someone!