Removing mappings and files

[staljaard-zz]

When updating my package to remove mappings and remove the files from the repo, the composer update does not actually remove these files from the magento dir.

[Flyingmana]

which deploy method are you using?

which version of the installer?

[staljaard-zz]

Hi

I'm using 1.3.2 of the installer and 1.0 of the command integrator and I've tried copy and symlink deploy methods.

So just to be clear, i'm not removing the entire package, just one or two files from the package, I did this by removing them from the repo as well as the mappings.

Thanks Shem

[staljaard-zz]

anybody else have this problem, it's a real pain for our dev environment. The only way to fix this is to clear out the magento root-dir and run the composer update command which isn't a viable dev process.

[Flyingmana]

its a well known problem which exists since the first day of the project with the copy based deploy.

noone had the time yet to actually create a method, which removes only the deployed files of the single module.

[staljaard-zz]

Hi, if I had the time, how would I go about this...

How would the update or the integrator deploy command, know which files were removed? There would need to be a way to diff the current module mappings to the mappings in the repo? would the composer lock file have a record of the modules mappings?

[Flyingmana]

there are sure different possible ways to do this. I think the composer.lock is not the right place, as Iam afraid to get in conflict with composer functionality. Also the vendor directory is not the right place, as the state of deployed files probably should be part of the vcs(because not everyone uses the gitignore feature and some commit the deployed files into the vcs)

in general, you need to manage a file, where you add every deployed file. This can be a single file in root, or a file in the deploy target directory. Maybe you want to group the entries by the package they come from.

Creating this files correct would already be a big step.

next comes the cleanup phase, you have to decide, do you want to cleanup before or after the next deploy. Means, removing everything of the module, before deploying it again, or wait till you update the file in the end, to make a diff to get the files which should now get removed. Here is also the question, do we create/update this file before or after the deploy, for the case the deploy got into an error, which means, the file would not get created after the deploy.

Thats what i currently have in mind for this, only ideas, would need some trying if things really work out. If you have another idea/plan, that would be also ok. You dont need to create tests if it makes to much work for you to figure out how they work, I could create them later.

[staljaard-zz]

cool thanks for the ideas.... will keep in contact about this

[Flyingmana]

should not happen anymore with the 3.0.0-beta.1 release