search

chrisboulton / php-resque

PHP port of resque (Workers and Queueing)
MIT License
3.43k stars 759 forks source link

Don't commit composer.lock for a library! #308

Closed danhunsaker closed 5 years ago

danhunsaker commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

danhunsaker commented 7 years ago

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 commented 7 years ago

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".