Composer update "overwrite" questions automatically answer with yes. Is it possible?

English forums
,
1

Since I change some shops from OXID4 to OXID6 and in the context of many refactorized modules, I have to relatively often use the composer update command to see if the modules install themselves clean. In a shop with 20 modules, the question of whether the module should be overwritten is always very eye-catching.

Is it possible to answer the questions automatically? The composer options known to me (https://getcomposer.org/doc/03-cli.md#update-u) are not suitable for this.

2

Yes i think this should default to YES also.

3

@leofonic: But you also do not know a solution for it?

4

You can change the default here:

But it will be overwritten sometime.

5

And then use composer update -n

6

@leofonic : Yeah, thats interest. I´ll check the class because there is another unclean solution. During Oxid-“Overwriting”, the old unessessary files wouldnt delete. Composer himself is in this case cleaner: Old unessessary files are deleted during update. You´ll didnt found the old stuff in \vendor\YOURNAME\YOURMODULE*. But you´ll found it in the modules \source\modules\YOURVENDOR\YOURMODULE*
Often it is unprolematic, but in case of old unessessary translation-files, the content of the files would still be scanned by OXID.

7

Yes there is no deletion at all in source. If you’re working on one specific module, maybe you could delete the module folder source/modules/yourmodule before running “composer update -n”. In this case Oxid installs your module from scratch again while leaving the other modules untouched, and you don’t have to answer all the questions.

8

@leofonic, @kermie : FYI: I create a “housekeeping”-Plugin for OXID6 Installations: Plugin on Packagist

  • The Plugin deletes the unessessary demo-images from OXID6 source.
    • This can be dropped once the OXID6 developers remove the demo images from the oxideshop_ce repository
    • I´ve discribed the problem here
  • The plugin removes the shop modules before they are copied anew by the composer-installation. This prevents the inquiry as to whether the modules should be overwritten.
    • This option is not for live systems, but very helpful during development (see above).
  • My installation- and update-process is much faster :wink:
2 Likes
9

its not necessary to use the compilation, so you can decide which packages you would like to install. you can create an clean oxid project (without using composer create project) with the following composer.json:

{
	"name": "oxid-esales/oxideshop-project",
	"type": "project",
	"description": "OXID eShop 6 Package",
	"license": [
		"proprietary"
	],
	"minimum-stability": "stable",
	"require": {
		"oxid-esales/oxideshop-ce": "v6.2.*",
		"oxid-esales/oxideshop-unified-namespace-generator": "v1.0.*",
		"oxid-esales/oxideshop-doctrine-migration-wrapper": "v2.1.*",
		"oxid-esales/oxideshop-db-views-generator": "v1.2.*",
		"oxid-esales/oxideshop-composer-plugin": "v2.0.*"
	},
	"require-dev": {
		"oxid-esales/testing-library": "v4.0.*",
		"oxid-esales/coding-standards": "v3.0.*",
		"oxid-esales/oxideshop-ide-helper": "v3.0.*"
	}
}

so no demodata, payment modules, … will be installed.

also you can cleanuo your modules folder with an pre-command like this:

{
	"name": "oxid-esales/oxideshop-project",
	"type": "project",
	"description": "OXID eShop 6 Package",
	"license": [
		"proprietary"
	],
	"minimum-stability": "stable",
	"require": {
		"oxid-esales/oxideshop-ce": "v6.2.*",
		"oxid-esales/oxideshop-unified-namespace-generator": "v1.0.*",
		"oxid-esales/oxideshop-doctrine-migration-wrapper": "v2.1.*",
		"oxid-esales/oxideshop-db-views-generator": "v1.2.*",
		"oxid-esales/oxideshop-composer-plugin": "v2.0.*"
	},
	"require-dev": {
		"oxid-esales/testing-library": "v4.0.*",
		"oxid-esales/coding-standards": "v3.0.*",
		"oxid-esales/oxideshop-ide-helper": "v3.0.*"
	},
    "scripts": {
        "pre-install-cmd": [
        	"rm -rf ./source/modules/*"
        ]
    }
}
10

@tabsl: Thanks for your answer. I have an almost identical, minimalist composer.json like you. I also do not install unnecessary payment modules and demo installers anymore.
Unfortunately, the demo files are currently still in the main repository, although there is already a separate Demo-Data-repository for this. That’s why my idea to delete the pictures in retrospect. But @kermit brings the problem already in the OXID developer group (see forum-link above). So it’s just a matter of time.

Your pragmatic approach…

…is awesome.

In the end I’m not sad about being able to deal with composer-plugins. :wink:

11

seems so … so feel free to make an PR :wink:

12

Hi,

don’t know if this is still current, but i’ve submitted a PR to avoid these messages with “extra” options in the root composer file.

Maybe this will help some devs.

Greetings
Sascha