Module update with composer - postupdate script

I actually meant this PR: https://github.com/OXID-eSales/oxideshop_composer_plugin/pull/19

Ho!

Symlinking in Windows is no problem. Contao is going a good way, they only symlink assets. And only if a module has a directory named public.

We started a new way, last hackathon, how to implement packages a bit more symfony like. https://github.com/OXIDprojects/oxid-symfony-kernel (In hope, someday, some more devs has some time ;D )

I had not much time in the last months, but we can install packages and only legacy-code, which must be located in /modules, will be copied. Here i have demo package: https://github.com/Sioweb/OxidApi All code from /src/Resources/oxid will be copied to /modues/PackageName

And if we could use a newer symfony version some day, we have access to Encore, a nice solution to parse assets with Webpack.

Maybe it makes more sense to add a section to composer.json with a list of files/directories to copy. Let’s say we have a deliverydate module with some login in the backend (validates the delivery-date and saves it to the order etc) and a datepicker which should be displayed during the checkout. We can then say which assets should be copied / symlinked from the vendor folder like this:

{
    "name": "alfredbez/deliverydate",
    "type": "oxideshop-module",
    "extra": {
        "oxideshop": {
            "target-directory": "alfredbez/deliverydate",
            "assets": [
                "out/src/datepicker.js",
                "out/src/icons.svg"
            ]
        }
    }
}

All PHP files can stay in the vendor folder. I don’t like the approach to have 2 modules for that: one (oxideshop-module) for the backend logic and one for the frontend-files (oxideshop-asset).

Interesting projects.

My problem is that modules contain template files, css files, js files and images. These are frontend files that should be modifiable by the user, one way or another.

Copying modules to source is not really code duplication to me, because only one copy is actually used. Afaik you can already choose to use the php files in vendor by pointing your namespace there. By linking the module folders to vendor you would take away any possibility to make modifications, just to save a couple of bytes.

1 Like

Hey there,

All PHP files can stay in the vendor folder. I don’t like the approach to have 2 modules for that: one ( oxideshop-module ) for the backend logic and one for the frontend-files ( oxideshop-asset ).

I second that. The division into two modules only makes sense if the modules you receive are not interdependent and are loosely coupled. In this case, you would get two modules that are tightly coupled and interdependent. This is dependency hell.

Copying modules to source is not really code duplication to me, because only one copy is actually used. Afaik you can already choose to use the php files in vendor by pointing your namespace there. By linking the module folders to vendor you would take away any possibility to make modifications, just to save a couple of bytes.

I personally do not like the idea of having the source code for a module lying around at two different places. I would always have to guess or lookup somewhere what code is executed. There should be only one instance of the code, and in my opinion it should be in the vendor directory. Coping files around adds nothing but complexity for no profit gained.
The assets need to be copied over for technical reasons, the idea with the assets key sounds nice at first glance.

Just my two cents :wink:

/Flo

1 Like