Symplify: [ECS] Regression in 7.2.3 - vendor_dir no longer working

Created on 2 Mar 2020  路  3Comments  路  Source: symplify/symplify

Moving from #1795 which may be a different issue.

We use:

imports:
    - { resource: '%vendor_dir%/lmc/coding-standard/easy-coding-standard.yaml' }

Now we are getting

> ./vendor/bin/ecs check ./src/ ./tests/ --ansi
PHP Fatal error:  Uncaught Symfony\Component\Config\Exception\FileLocatorFileNotFoundException: The file "%vendor_dir%/lmc/coding-standard/easy-coding-standard.yaml" does not exist (in: ...). in .../vendor/symfony/config/FileLocator.php:71

The whole class ParameterInImportResolver which takes care of vendor_dir placeholder is missing in 7.2.3 (but was present in 7.2.2).

It seems to be removed in #1752.

The issue is removal of the feature was done in as part of bugfix release, effectively breaking workflows for anyone using imports in this way, simply after updating the package from 7.2.2 to 7.2.3.

I believe this is not how bugfix releases should work, isn't it? Changing of the behavior should be done in major releases. Also there was no time for upgrade, it was not marked deprecated before etc.

Most helpful comment

fixing + BC change at same time

And if so, it simply must be part of major release, as per semver.

Well imagine you have 10 teams, each using the import. They run regularly composer update. As part of bugfix release in ecs, they have all now broken builds which needs manual intervention in potentially tens of repositories, because everyone would need to change the way how they import our shared codestyle.

This behavior was part of ECS for two years, you even personally suggested it to us... And it was removed from day to day because of bug in some feature added to ECS two months ago... While I understand it from yours point of view as the package developer, I strongly don't like this attitude "hi there, you get backward compatibility break in bugfix release with no heads up" seen from someone who uses ECS in tens of their packages. 馃槙

All 3 comments

I understand it is BC change. It was breaking ecs.phar though, so fixing + BC change at same time. I didn't bump mayor version, because it's too soon for it. Saying that, knowingly breaking semver for mentioned reasons.

Upgrade path is in #1752

fixing + BC change at same time

And if so, it simply must be part of major release, as per semver.

Well imagine you have 10 teams, each using the import. They run regularly composer update. As part of bugfix release in ecs, they have all now broken builds which needs manual intervention in potentially tens of repositories, because everyone would need to change the way how they import our shared codestyle.

This behavior was part of ECS for two years, you even personally suggested it to us... And it was removed from day to day because of bug in some feature added to ECS two months ago... While I understand it from yours point of view as the package developer, I strongly don't like this attitude "hi there, you get backward compatibility break in bugfix release with no heads up" seen from someone who uses ECS in tens of their packages. 馃槙

@OndraM We keep having issues with ecs as well. I've lost count how many breaking changes we had on minor version increments. So far we only reported one as part of #1492. I was going to report this vendor dir one as well, but you did it before me.

I'm starting to doubt that using ecs is actually saving us time. The library is extremely volatile and with each update we spend time finding out why it breaks.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

azdanov picture azdanov  路  8Comments

shyim picture shyim  路  6Comments

nunomaduro picture nunomaduro  路  8Comments

TomasVotruba picture TomasVotruba  路  7Comments

crazko picture crazko  路  9Comments