I am writing a small CLI command that diffs files that exists in your project space and vendor. For

UM4BZSK7T

I am writing a small CLI command that diffs files that exists in your project space and vendor. For example if core updated you can diff and see if your version is still up to date. I am doing this on filepath base. I believe Spryker keeps track of any file I override from core. Maybe that is better to be used? Is that file map cached and usable somewhere?

Jeremy Fourna

@UM4BZSK7T your CLI command will be very interesting indeed, will you be able to share it with the community or with our Spryker Architects to see how we can help?

UM4BZSK7T

I would love to put in on Github as MIT and we can collaborate but I wait already for some weeks now for the Spryker Team to tell me if I am allowed or not... So currently sorry I can't 😭

Andriy Netseplyayev

Can you elaborate a bit more on
For example if core updated you can diff and see if your version is still up to date

Andriy Netseplyayev

what means “still up to date”?

Andriy Netseplyayev

are you trying to prevent issues during Spryker update?

UM4BZSK7T

Spryker is like Drupal. You have a magic system that overrides a file from verndor with your own version. https://documentation.spryker.com/docs/core-extension#extension-via-replacement

UM4BZSK7T

As we do this frequently as soon as we update the vendor package we have to check for changes.

Andriy Netseplyayev

yes, that I understand. But what’s your criteria on “still up to date” ? Or what do you want to achieve here?

UM4BZSK7T

A diff so you can more easily guess if to adapt changes.

UM4BZSK7T

I override MyClass->fancyMethod(). And add something I need. Now in Spryker core the ->fancyMethod() is extended as well. For example with some security checks. I will never ever know that that happend if I won't look in the code. So what would be better than a DIFF 🙂

UM4BZSK7T

Currently I do this. But thats really raw and fixed

giovanni.piemontese

spryker-sdk/composer-constrainer

help to know at first which modules u have to constraint to ~ instead ^ to avoid collisssion update...

u can maybe start from this point to know which files are on pyz overriden and then maybe your diff logic

UM4BZSK7T

Thanks that is interesting and rather close to what I do except the goal is different.

Andriy Netseplyayev

okay, that’s what I thought (what you’re trying to solve).
Another direction you can look into is to re-inforce on your project a rule, that whenever you overwrite a spryker class, you do

SomeClass extends SprykerSomeClass

and try to search for such occasions. F.e. a code-sniffer could that. Could it be possible to implement a custom sniff, that would do such check (thinking out-loud) ?

Andriy Netseplyayev

on one hand, you could detect which files you have changed, but on the other hand - you would need to get core modifications and “raise a flag” ..?

UM4BZSK7T

@UKJSE6T47 Going for the extends SprykerSomething is a good idea. But I believe the diff would be very useful and I don't think codesniffer can do that?

UM4BZSK7T

In the end I don't think there is any possibility to do that automatically. So make it as easy for a human to review the changes.

Andriy Netseplyayev

of course, you have to stop automating when it makes sense. Only human can decide, if that will still work, unless you have 100% code coverage and rely on running the tests after each minor update and see what will fail

Andriy Netseplyayev

I don’t think codesniffer can do that?

yes, sniffer can find classes you extend. But how to get a diff - is already a “custom” part, which is PHP. That could be the procedure:
1. get composer outdated info for the module of your class to get your version / actual version.
2. get the code diff, f.e. https://github.com/spryker/catalog/compare/5.5.1...5.5.2
3. grab somehow list of files / methods changed (can be tricky.. or not?)
4. conclude if you have overwritten the method/class or not

Andriy Netseplyayev

But I honestly never tried that, not sure how you can get that. Maybe github has some API that could allow that?

Andriy Netseplyayev

you can split the work by a) preparing/caching info about classes changed “since your version” and b) running a sniffer and checking if your class is in the (static) list from (a)

UM4BZSK7T

Interesting thought but it involves a lot different tools. I believe in our case it is okay to check after you did the composer update. I locked anything to tilde anyways. And I won' t trust tests if some new and rather unexpected features might be added. So I will now check if I can reflect all my classes in my project and find all overriden methods. https://stackoverflow.com/questions/2669046/php-get-overridden-methods-from-child-class

UM4BZSK7T

What I am currently think about is if the filepath method wouldn't be still the wisest in the end so I could check xml and maybe yml files as well.

UM4BZSK7T

https://github.com/hanneskod/classtools That is interesting