Hi I’m trying to understand the usage of composer in oxid and have the following question:
When does the following check become relevant:
Update operation will overwrite <package name> files
Is there a situation where the user does not want to update the files when updating the module?
And when updating one module with composer update why does the postupdate also ask about overwriting all the other modules?
E.g. if you have custom theme, you mostly end up editing module templates to fit your theme. If you let composer overwrite your files, your customized module templates will be lost. Basically if you did any kind of changes in module files, they will be lost.
because composer is absolute BS. Thats how it works.
there a minority of modules placing config files and other data inside the modules folder.
I hate that decision to allow that modules to continue to work by having the project developer now to press n times no or yes when working with composer. a simple symlink should be used to install modules and would love more devs would peacefully race their voice to get rid of this anoying question and remove support for modules writing to their installation folder.
Maybe it would be a good idea to let the module developer decide whether files should be copied or symlinked?
that is a awsome idea, with win win for both side. making it better without bc break and simple to code.
Symlinks would probably not work on windows and i don’t really see the advantage because modules don’t use much hdd space anyway. Also no one could change anything in themes and modules anymore. Why not just default to “YES” so one could use non-interactive mode and get the same result?
But where are customisations supposed to go then? If custom changes are placed in an empty folder they will not be overwritten by a module update.
Composer cannot update only one module, if you do an update all components are checked for newest versions that meet the requirements. OXID’s composer plugin then copies modules and themes from vendor to source.
Composer cannot update only one module
If you only want to install or update one dependency, you can whitelist them
e.g. composer update my/module checks only this package afaik. It’s just that the oxid composer plugin which is triggered by the post-update-cmd event then cycles through all packages and asks if the files should be overwritten.
yes composer can update a single package by using composer update modulename and composer require modulename:version
I see what you mean now.
good point I thought native windows support is already dropped within oxid, so if this is a valid usecase then a clever default is also a alternative.
I think customisation should not be done in modules installed by composer, modules should be generic, configurable and easy to update. all other customisation should go in custom theme (e.g. by disabling blocks of that module), in other customisation modules and settings. This will make your project simpler to do upgrades and reduce upgrade costs. Anyway it may help to understand that I am try to reduce custom modules in my project in favour of generic modules that can be shared across multiple projects.
For custom modules I am used to place them inside module source folder directly (and only register them to composer to get the autoloading working, but not for handling updates)
Just for information - from the symfony docs:
// duplicates the source directory if the filesystem
// does not support symbolic links
$filesystem->symlink(‘/path/to/source’, ‘/path/to/destination’, true);
also I thought windows can do sth like symlinks but I didn’t check. The pro of symlinks in my opinion would be
but I’m new to oxid so I’m just trying to find out why it’s done as it’s done 
totally agree
Yes it is officially and i don’t like this also. But at least it works and they seem try to keep it that way.
That’s a good idea in general, but if you move module blocks to custom theme you have to remember to undo those changes before disabling the module. The advantage of using blocks is gone. And modules that do fontend changes cannot be generic.
I wish OXID would make this standard again and would take care of the autoloading. But some modules (and maybe more in the future) require other packages so this won’t work for them i suppose.
Yes it can but this does not mean a solution would work on windows. Maybe it would but maybe not, i don’t know.
But the code is duplicated in order to move it into user modifiable space. No decision would also work with the default to “YES” suggestion. But i agree that it should be possible to update just one module, i just didn’t understand the intention at first.
thanks for answering!
I think default to YES is dangerous if modification should be allowed (this way all modifications would be overwritten?)
That’s why it defaults to no i suppose. But in interactive mode you could still prevent overwriting by hitting no. I think best solution for modules is to provide space for modification that is not overwritten in any case, like custom themes in OXID. OXID does not provide a standard for this, but it is possible. But this only works if modules reside in source folder and not in vendor.
are there any reasons why modules still need to be copied over into web accessible directory except js/css and images?
OXID files are kept in vendor folder, so could be module files, too?
With an asset manager all module js and css files could be automatically included into one single minified file. But i have no idea yet, how to handle module images.
I was wondering that too why the oxid composer package type does code duplications. Yea for static assets this makes sense but I still don’t understand the duplication part. Why not handling it like other systems (eg. typo3) and define oxid composer packages to be installed in the modules directory only and omit the vendor directory completely?
Defaulting to yes is also a good idea, I think. In combination with Keywans PR [1] this would make composer in oxid projects much more convenient.
Tbh I’m not a big fan of coupling the frontend build process to the backend in any way because this often involves database state and therefore is a nightmare to get into version control.
[1] https://github.com/OXID-eSales/oxideshop_composer_plugin/pull/18
maybe we could get another new package type like “oxideshop-asset” which will be installed in a web accessible folder, so “oxideshop-module” packages could stay in vendor.
Or modules could become regular packages and require their assets as “oxideshop-module” packages if needed.