Composer cleanup

[TomasVotruba]

Althought it is very useful in some cases, having composer.lock doesn't make sense for small packages like this.

This SO answer nicely summes it up

[TomasVotruba]

I have no idea why Scrutinizer failed, neither shows the Scrutinizer

[jaapio]

I don't agree with you. Since it doesn't have an impact on the users of the library. But it allows us to be sure that we don't get any strange side effects on updates. I'm not convinced by the threads on stackoverflow. I will leave this PR open for discussion.

[TomasVotruba]

It has actually negative effect on development, because of constant commiting new composer.lock to git. Huge diffs for small changes in code.

Have you came across any real conflicts due to missing composer.lock in this package?

[peter279k]

Hi all. After I checkout the Scrutinizer log, it has the dependencies problem.
The final error message is as follows:

Analyzing composer.json/composer.lock files to determine dependencies of the root package.

Perhaps the composer.locck caching some dependencies so that it will be the conflict problem.

[TomasVotruba]

@peter279k I used Scrutinizer in 12 repositories with only composer.json with no problem. That's probably not the issue.

@jaapio Would you be open to move coverage checks to Coveralls like on the other repo?

[jaapio]

Would you be open to move coverage checks to Coveralls like on the other repo?

YES I am, sir 👍

[peter279k]

According to the #128, this #128 PR is merged and I think this PR will not have the big issue to solve 👍 .

[jaapio]

I'm closing this PR since I want to leave the composer.lock in place so we don't have any strange bugs that are popping up during development of unintended external issues. Please open an issue for discussion about having a composer.lock in libraries or not.

[TomasVotruba]

@jaapio I will push it soon then.
Btw, have you thought about monorepo for phpDocumentor? These duplicated changes and mutual package development asynchronicity are quire exhausting. It would improve further development a lot.

I have no issue with composer.lock if you find it useful here, I respect it.

[jaapio]

Fact is that most of our components are used by other projects. I agree that the maintenance of packages is very time consuming. But I think we can't go back to one repo because of the usage of the packages.

[TomasVotruba]

I don't mean one repo, I mean monorepo, like Symfony is.

Every packages distributed by itself but maintained in single monorepo.

It has many advantages.

[jaapio]

It also has disadvantages. Like discussed in zend framework

[TomasVotruba]

I don't know Zend, let's be specific to this project.

In case most of packages are out of date and unmaintained (not developed), in low numbers and with burn-out history for many of them, this might be a way to bring them to life. Moreover when it looks like you're the only one around in this organization.

Why do you think it would hurt this project?

[jaapio]

Basically we have 4 repositories that are actively maintained.
3 reflection and our main project. All other repositories are unmaintained. And not even used by anyone at all.

The main issue I see is that we are currently able to have bc breaks in all of them separately which acually makes sense to move faster forward.

[TomasVotruba]

The main issue I see is that we are currently able to have bc breaks in all of them separately which acually makes sense to move faster forward.

That's possible even with monorepo. Is that real issue when TypeResolver itself has 2 releases per 2017?

I think monorepo is much better to handle BC breaks, because package depend on each other. Now it would be easier to bump to PHP 7 in one way, instead of doing it individually in asynchronous timing.

I wrote about advantages of synchronization here, if you've got 5 minutes.

Also my motivation is to make these package more usable. I've used them in ApiGen, with dependency on BetterReflection, that uses ReflectionDocBlock, which uses TypeResolver. Finding a bug/needing a feature in TypeResolver after many weeks/months of waiting on issue resolution followed by tagging I gave up and rather made my own TypeResolver fork or hack it with reflection.

That could be avoided much more easily by using monorepo for (at least) these 2.

[TomasVotruba]

But if you have bad experiences with monorepo yourself, no need to push this. I've tried both approaches for ~2 years each and monorepo is absolute winner. I also use Symfony ecosystem, so I understand you using Zend have logically synced opinion on this.

I've also helped to maintain Nette framework going throught same way as Zend and it caused lots of bugs with not real added value or real reason to keep it that way, apart status quo. An experiment not worth reverting.

[jaapio]

Thanks for the read.
I don't have that much experience with the monorepositories. Only thing we had in our company library was that we had many tags on repositories that didn't defer. I'm open for your opinions :-)

Because we are much stronger together then when we are doing our own job on equal packages. Your energy on these packages gives me energy to continue developing them. We are doing more than enough duplication in the php community.

I would like to plan this idea together with you to see how this would work out with the limited resources we have in the phpdocumentor project. Which is currently not in a very active development flow.

[jaapio]

I will create an issue for this in the main repository of phpdocumentor. I would like to invite you to join me to start working on a more effective workflow for the packages in the phpdocumentor organisation. I will comeback to you soon

[TomasVotruba]

@jaapio Thanks for such a nice words. I'm glad you're open to not-small change.
That's very rare these days, moreover in open-source.

I'm very happy you have fast responses to my PRs, I see you care about this.

Take your time, I'll look forward to you.