Don't commit composer.lock for a library!

[danhunsaker]

It's generally a bad idea to lock external requirements down to a specific revision in a project that will, itself, be required by others. Remove composer.lock, prevent it from being re-added, and allow Composer to select an appropriate version given other external libraries pulled in by the end developer.

[chrisboulton]

I don't think I actually buy into this in general, and it's a conversation I've had with other libraries - my understanding is that in consumption of a library in some application, only composer.json is used for determining and resolving dependencies, so consumers should be fine. The lock file is ignored.

What composer.lock is useful for is for me actually developing php-resque, to ensure dependencies between local development & test (w/ Travis) aren't changing.

Are my assumptions are wrong.

[rajibahmed]

I agree with you Chris, in Ruby world Gemfile.lock is important, npm don't have locking thats bad, composer locking I would say should be used for integration tests and deployment of main application code.

[schmunk42]

@chrisboulton I'd also 100% agree to your statement.

[danhunsaker]

Fair points, though I'd argue that locking the versions you test against will only ensure the locked versions work properly, not the versions users would actually encounter in their own projects. Instead, I'd personally recommend testing against the most recent versions, as well as the oldest, pulled in by your composer dependency declarations, and then tuning those if necessary.

[schmunk42]

testing against the most recent versions, as well as the oldest,

... as well as all combinations in between, eg. because of constraints of your PHP version. That's not really feasible.

Locking a lib is absolutely fine for development, otherwise everything is "flying target".