Committing a generated Symfony container limits the Symfony compatibility

[stof]

A container dumped with a version of Symfony DI is not guaranteed to be compatible with a different major version of the component (and I'm 100% sure that there is such incompatibility between 3.x and 4.x. I'm not sure about 2.8 vs 3.x)

So this would force you to generate a different version of the container per version of Symfony.

[stof]

Btw, there is no documentation about how it is generated.

[goetas]

This webservice client is generated using https://github.com/goetas-webservices/soap-client

For users that need a more "granular" control over the container, endpoints, namespacing, dev mode, and many other things, https://github.com/goetas-webservices/soap-client should be a much better tool.

This project ships a config.yml, using goetas-webservices/soap-client and running

bin/soap-client generate config.yml dest-folder --dest-class=container-fqcn

will produce exactly this client.

here are explained some additional parameters supported by the current config.yml format.

[stof]

@goetas the issue is that this project composer.json does not specify a dependency on the DI component. The one inherited from soap-client means that the component will be there. But while soap-client could easily update its requirement to allow 4.x (assuming the code is compatible), this project cannot: it will work for the version of Symfony used to generate it, not for all supported version of Symfony.

So you should at least have a stricter dependency here, based on the version being used for generation, or change the way you distribute this library to avoid sharing the generated class.

[stof]

btw, the instruction you give here about the way it is generated should be documented in this project (in a CONTRIBUTING file maybe). I actually found the soap-client script from goetas-webservices/soap-client already and guessed it was used, but other wannabe-contributor might not make the same investigation.

[goetas]

So you should at least have a stricter dependency here, based on the version being used for generation, or change the way you distribute this library to avoid sharing the generated class.

You are right, adding a strict dependency on composer sounds a good compromise to me

[stof]

but it forces you to make new releases based on the Symfony version, which complicates the versioning if the client also needs to evolve based on upstream changes.

[goetas]

The idea situation in my mind was that for small projects this could be good enough, while for come complex stuff people will use goetas-webservices/soap-client... Am I too optimistic?

[stof]

dunno. I'm not actually using that project. I found it when you tweeted about it, I was curious, and I though about the impact of sharing a generated DI class with my knowledge of the internals.

for small projects this could be good enough

it would be good enough if they can have a version compatible with the version of Symfony they use.