[Theme] [RFC] Strategy about module/theme and asset management

[Guite]

Background and context

I looked into #3908 and started reading. The problem with this issue is that when you start replacing the component-installer you immediately end at the question how we treat assets and libraries in general.

1. General libraries (in the core)
2. Module / theme / bundle specific assets

For the 1st part the component-installer uses "component-dir": "public" in our composer.json file and each component (jquery, jquery-ui, etc.) specifies which assets to process (example).

What is missing

Beside the component-installer being deprecated we still have no real asset management nor support for yarn and all this stuff (see #3946). We are also not using Webpack Encore yet (see #3601). Which is of course not easy in a system which consists of several different modules etc. Also we want/need that connected to composer (see #3273, #3438, #3804, Symfony Flex). There are also thoughts about unifying modules and themes (see #3644) and treating them as vendors in future.

Time to look what other's do.

Alternatives

The component-installer readme shows three alternatives:

1. https://github.com/oomphinc/composer-installers-extender
2. https://github.com/hiqdev/asset-packagist
3. https://github.com/fxpio/composer-asset-plugin

The third one is the most popular one. But it's new version is incompatible with older ones and became a new project:

4. https://github.com/fxpio/foxy

How about other projects?

Other PHP projects have similar requirements. Here is some related reading material:

• Add support for installing libraries via asset-packagist drupal-composer/drupal-project#278
• Asset management in Yii 2.1 yiisoft/assets#7
• Add "provide" information to composer.json fxpio/composer-asset-plugin#330

What next

For all these changes we need to agree about the direction we are heading to. Otherwise it is difficult to prioritise things and tackle them one by one.

[Kaik]

It might be irrelevant or off topic but...
So...
Copying files from one place to another during installation is not the problem I guess.

Both composer and yarn/npm are dev tools. Both of them are designed and used to compose/build sources into artifacts, which are then tested and deployed.

When build is deployed it should not change.

While we (and other cms) want to add additional packages during production which means, we want to recompile stuff in production.

At the moment our 3rd party modules are bypasing composer when you install them via web, and this works because PHP is mostly interpreted "on the fly". If someone needs 3rd party php lib in his zikula module there is no way to install it via composer, you have to supply it with the module(which is bad).

Even bigger problem is with assets. Webpack (actually npm and yarn) is awesome but it is like composer. The only difference is that it combines all sources into artifacts, which are then being deployed. (I think it will work without being compiled/combined altogether.. maybe? is it even worth checking? it will be huge if not combined and minified)...

We do not use proper new age js, our js framework is jQuery... ;)

So options:

1. We will build a cms that allows to rebuild its own source online (composer and yarn/npm on production server)

2. Zikula will have to be pre-generated before (I think there was an idea like that you could select core version, modules and stuff... it was some time ago... like 2010 or something :)...) modules will have to be added to registry, tested and stuff... this would be reasonable but what with custom things like custom theme... (user uploads his theme source and we do all the composing building online) and what will happen when user want's to add new module?

3. We will provide strict base that is compiled and then additional modules will have to work as they do now, no composer/webpack level integration... just plain css, js and that's it... copy files into web dir and then load them... modules will be restricted to use what they can use (what works without compiling assets) we just need to write script to copy those files

4. We will teach our users "THE DEV WAY" to download Zikula/ZikulaComposer/ZikulaBuilder/ZikulaStudio... start it locally add all modules and themes and stuff and then build artifacts that are then deployed online... It is some sort of version 2 and current composer/node way, but done by user...

The problem with building on production is security and size of all those files... so 1, 2, 4 are kind of the same, only the building itself happens in different place.

5. I guess it would be perfect if we could provide whole suit where you can build -> test -> deploy then rebuild (upgrade/add/remove/modules) -> test and deploy... so you install online whole ZikulaCreator, then you compose your Zikula with all modules and themes and stuff then it is tested and then deployed to some sort of "public folder" from where it is delivered as zikula installation... when you want to make some changes then you open ZikulaCreator again make changes test them and then deploy...

The only problem with this solution is that we do not have enough resources to pull this off :)

Above is not really relevant to what is the issue about, but overall it is, at least in my opinion...

[Guite]

Closing because this is not our business anymore.