bin/install.sh doesn't finish with Composer 2 as robloach/component-installer package is abandoned

[kaustabhbarman]

While running the bin/install.sh, the installation doesn't complete with Composer 2. The robloach/component-installer package is abandoned in Composer 2. Atleast this is what I could understand from here and oomphinc/composer-installers-extender is recommended to be used instead as it is marked as compatible with Composer 2.

This is the error that I get using Composer 2:

Your lock file does not contain a compatible set of packages. Please run composer update.

Problem 1
- robloach/component-installer is locked to version 0.2.3 and an update of this package was not requested.
- robloach/component-installer 0.2.3 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.2.0] but it does not match the constraint.

For now, the only way to run it is by rolling back Composer to version 1.

[j3nsch]

Did you try using the new package to replace the old one?

[j3nsch]

We need a proposal for replacing the outdated component-installer ASAP. The installer is used to install JQuery.

"components/jquery": "3.4.*",
"components/jqueryui": "1.12.*",
"robloach/component-installer": "*",

The path for the installation is configured in composer.json as well.

  "config": {
    "component-dir": "public/assets"
  },

What do we use in the future? What is the currently recommended way of doing this? Please create an PR with the necessary changes. Thank you!

[kaustabhbarman]

I have changed the plugin to a new one - oomphinc/composer-installers-extender and it seems to be working by installing jquery in our custom path - public/assets. However, before I push it, I see that the older plugin also puts four files in the same directory - require.config.js, require.css, require.js, require-built.js. I would like to know if these files are auto-generated, put by some other plugin, or placed by the older plugin there. If it's placed by the older plugin, then what could I be missing?

[j3nsch]

The old component-installer seems to have been designed to be used with RequireJS (https://requirejs.org/). We are not using that, so the files are not important. They are autogenerated. The "components" being place in public/assets should be sufficient.

[j3nsch]

So, I think that is ready to be pushed. I think it would be useful to create a unit test that checks if the components have been installed. Before a test run on GitHub, the composer dependencies are installed, so the JQuery folders should be present. You should create a class like ComposerTest in tests/modules (not the perfect place, but good enough) and simply check, if the correct folders are present in public/assets. Any serious problem will probably be detected by Composer, but if we mess up the configuration, the path, we won't notice automatically. Thank you!

[j3nsch]

Is removing the plugin-access part the right choice? It is not something that we can delegate to the people installing OPUS 4. It isn't optional. We need the components, so these plugins need to be able to execute code. Are there alternatives?

If we did leave it to the users during installation we needed to document this, because otherwise any sensible user will say "no". Any other thoughts?

[j3nsch]

Any idea why Composer asked for permission on your system? It doesn't on mine. I am using Composer 2.1.9.

[j3nsch]

Need to get those changes into the patch release 4.7.0.8 as well, since the master branch is affected by the same problems.