Provide a ludwig.json without using lock file

So far I've demonstrated how to generate ludwig.json with composer, but install it without composer (with Ludwig).
I use composer.lock only for generating ludwig.json. I don't use it to install the module, and it does not need to be in the production site.

Since all modules declare their dependencies in composer.json, it makes sense that composer is used somewhere to get the dependencies. The end user should not need to do this.

Once a module is converted, the resulting artifacts can be made available for public download, so that somebody that does not use composer at all can download them and install them. I propose that the drupal.org packaging system does this for all the modules. It requires some staging work, but it doesn't seem huge. Once done, it would provide a mechanism to install any module without composer at all. It could be done in batch mode, sequentially (simpler), or it could be done on demand and cached (more complex). I just checked and there are currently 6445 8.x modules (2537 modules with stable release). If it takes 1 minute per module to get the dependencies and repackage them in ludwig-ready form, it would take 4,5 days to process them all. Many modules don't have dependencies, so they would not need to use composer at all. It would be faster if there were a composer flag to not search the repositories for a library if it already has a version of it in its cache, but there doesn't seem to be such an option. We could make such a feature request.

Then perhaps this repackaging could be done whenever a module changes. Some reprocessing would be necessary whenever there is a new release of drupal core, in order to figure out which libraries need to be installed and which are provided by drupal. This part should be much faster, because it does not need to use composer.

If I could download all D8 modules, I could try doing such a batch conversion.

It's not really a module yet. It's a little bit of code that automates the work that the Ludwig asks module maintainers to do.

I think d.o should provide the service. I think it can be fully automated, so why depend on module maintainers to do it? Are we going to chase them to do it? I've already mentioned it in a comment to an existing idea, and may also propose it separately as I get a better grasp of it and present it better.

In order to not change the existing module packaging, the service could provide for each module with dependencies, a companion module that contains those dependency libraries. So users would download two modules and install them as they always did. In addition, of course, to the Ludwig module.