SuiteCRM 7.10 beta - composer.lock has been removed and ignored

[isleshocky77]

It looks like the _composer.lock_ file was removed and added to _.gitignore_ during the Codeception Feature branch. I've never seen a project do this. Is there a valid reason for not having the _composer.lock_ file not part of the source? It is a way to make sure that the correct dependencies are being used with the current code. I can see for making more open dependencies in the _composer.json_ file, but I can't see not having _composer.lock_ file. It appears it was done without any type of comment on other than the commit message saying "Codeception: Updating travis ci configuration"

Issue

When installing the project you get the latest version of every dependency instead of having an intended version which is known, developed, and tested against.

This is also much slower than already knowing the correct versions.

Expected Behavior

When installing from _composer_ there should be a _composer.lock_ file with the intended versions of dependencies.

Actual Behavior

When installing the project you get the latest version of every dependency instead of having an intended version which is known, developed, and tested against.

Possible Fix

Remove _composer.lock_ from _.gitignore_ and commit the current _composer.lock_ file after running _composer install_

Steps to Reproduce

1. Checkout Source
2. run _composer install_
3. notice checking for entire dependency graph

[Dillon-Brown]

This was an intentional removal. We don't need auto-generated files like composer.lock in the repo.

[isleshocky77]

Was there any type of research or anything you guys looked at to come up with that decision? I haven't heard of projects not committing the .lock file.
One of the first things I ran across was this :
https://m.dotdev.co/why-the-composer-lock-file-matters-c8d1e1488be7
And
https://www.engineyard.com/blog/composer-its-all-about-the-lock-file

But I'm having a hard time tracking down anyone talking about discarding the .lock file.

Once again, I don't mean to come off as a pain.. just wondering your motives behind it as I didn't see a pr or issue about removing it.

[isleshocky77]

@Dillon-Brown , sorry, forgot to mention @ you. I know you said that's mainly what you guys monitor.

[Dillon-Brown]

@isleshocky77 This was more of a design decision that doesn't have a "Correct" answer on whether to include/exclude composer.lock. When we create release packages for download they already contain a snapshot of the vendor folder which would be the guaranteed working version, the same as if you were using composer.lock. If you are pulling off of GitHub we would want you to use absolute latest dependencies so that if any issues do arise, you can let us know about them.

Thanks for the question! let me know if you need further info.

[isleshocky77]

@Dillon-Brown Once again, not trying to be picky; however, I really, really dislike this answer. You're essentially saying you think anyone pulling from source should be a guinea pig for unknown issues. Thoughts on at least committing it to master and the _tags_? Probably have your workflow add it back in on the _hotfix_ and _staging_ branches and just leave it off of develop so that it's got the latest locked into each staging and review process for testing.

[pgorod]

Without taking sides, let me just say I'm enjoying the discussion, and I would just venture saying we should look forward to the future, when I hope we will have better deployment options, including automated ones, and they should work well and be predictable.

[isleshocky77]

Yeah, I believe me. I get the hassles of having "auto-generated" files in the VCS as well as the hassles of conflict resolution when it comes to composer.json and composer.lock - it tends to almost look like technical debt.

I also hate it's easy to complicit in letting your dependencies stay as working and you end up with extremely out-dated dependencies with the worry of making major upgrades.

However, I also know the PIA it is when a dependency you had no idea about introduces a bug or issue. And I've had that literally from 3.5.1 to 3.5.2 and having to track it down.

I think a fair compromise would be to ensure you're upgrading between releases by not having the .lock file in develop. But I just can't see not having the .lock file on tags as then you're not really tagging the full source tree and unable to narrow down issues which may arise.

Obviously, it's your project, so you make the final decision - just my 2 cents

[Dillon-Brown]

@isleshocky77 I understand where you're coming from. I would argue that with updates being such a critical part of development (security, bug fixes), making sure that we have all of the latest dependencies would be an important enough reason to leave it off of Git. At the same time, I agree that having a known working/stable version is equally as important which we accomplish with the release package snapshot of vendor. I would hope anyone downloading SuiteCRM for production use wouldn't be running composer update in the first place!

In terms of using GitHub for "guinea pigs" I would look at more as using GitHub for "active development" where we would want to see any potential issue's raised as soon as possible. We do very much appreciate the discussion here and we'll definitely think more on this.

[isleshocky77]

@Dillon-Brown I get what you're saying about the "packages" you create being for production; however, also realize that in the opensource word, especially around github, there is a very real and useful process of being able to fork, patch, modify, change, etc and then be able to use in the real world without having to wait for a project to accept the changes back upstream.

By not having a stable line (branch [master] or tag) with known dependencies, you make this process less safe. It would mean we would have to pull the "package" and the push patches on top of it, rather than just rebase a branch on a stable tag or branch before making our own release package.

P.s. You can cut me off and say you've heard enough.. like I've tried to maintain, this is your project and the community will have to deal with the direction that you and the team decide to go in.

[horus68]

@isleshocky77 I can agree with you. A project needs to be neutral on the way people uses the software. Users need to be able to control things in a neutral way.
As for the actual project there should be a middle ground on the production requirements for a release and the public project.
So there should be a way using github system to allow both uses.
Will this require too much work?

[Dillon-Brown]

@isleshocky77 @horus68 I agree that having composer.lock in master and the tags is a reasonable request. We'll discuss this further before a decision is made for master/tags. Thank you for the continued feedback, we really appreciate it.