Open oojacoboo opened 5 years ago
I've run into the same issue with a project that uses only the following Symfony packages, not the complete framework:
Like @oojacoboo suggested, the DI component should be detected by the plugin, or at least offer a way to manually configure the service container.
Hello,
Right now, no configuration file is parsed. The container parameters and services are obtained via the console component, using the debug:container
command. This is the simpliest way to fetch container elements for projects using the framework (which is the primary focus of this extension). I don't think that parsing config files may be a good idea for these reasons :
That said, I'm looking for alternatives to not only support projects which uses Symfony DI component, but also support projects which uses the framework, but don't have the console component easily working for many different reasons. Right now, the most promising way to obtain the container elements is to parse dump files, produced by the XmlDumper
, YamlDumper
or PhpDumper
classes. This allows the extension to only rely on the DI component, while also getting the services and parameters directly from the compiled container itself.
I'm looking to implement the parsing of dump files in the next release.
Hey @TheNouillet is this what you're referring to here?
I'm curious if it would be possible for us to just add support for the command debug:container
to output what's needed. Can you tell me, from what directory the console command is invoked? That might be another issue since our dir structure isn't the same as the Symfony framework.
Looking forward to being able to specify the config.yml
(xml/php) config file directly and allowing this plugin to consume it.
Hello,
I'm refering to this :
The Symfony framework dumps the container into an XML file. This file can also be a YAML or a PHP file (might be more difficult to parse though).
For the console command, the directory is the same as the composer.json
file directory and cannot be overriden (yet ?). The console path (so bin/console
for the framework) is deducted by the framework version, but can be overriden by the symfony-vscode.consolePath
configuration.
Thanks @TheNouillet. We do actually dump and cache the service container. However, since we don't use the Symfony framework, none of this is standard. After digging into it a bit, it doesn't look like it'd be worth it for us to modify how things are setup to support this. I'm not even sure where this plugin looks for the dumped container config. I'm guessing in the cache
dir at the project root.
It'd be great if we could just configure the location of the dumped container config. This would allow us, and I'd imagine most people to use this with non-symfony framework projects, even if they have to add the dumping logic. This could at least be a stop-gap until dumping and caching is built into the plugin itself, based on the main container config file.
One other potential issue that we might have here is that we use Docker and the cached container config we throw into /tmp
, which is better for many reasons, primarily because our project src files can remain read-only allowing for another layer of security. But, also because /tmp
is recycled and is a proper location of cache files. The issue here though is that we'd have to support the following command to get the file.
docker exec -it container-name cat /tmp/Container.php
If this plugin would allow us to specify a file location or command to be executed, I think this could fix our problem and I'd imagine many others as well. Thoughts?
Hey @TheNouillet. Do you have any information on how you might register the debug command with a custom installation of the console? Or, is there any way to point this plugin to the actual cached yaml or php cache file?
I'd really love to be able to use this - would save me so much time, but it's so symfony\Symfony specific right now, I just can't seem to get it working. We use the console
bin script with commands and have some of our libs registered with it as well, but this debug
does not exist. I'm assuming that some kind of framework bundle or something?
See #39
@TheNouillet what do we need to do to support a config option to point to this XML dump? Will you take a pull request on this? Please advise. Thanks.
What is "Symfony" as a dependency? Is this looking for the framework lib, or what? We use the Symfony container service (DI) lib, which is primarily the purpose of this plugin, no? How can I tell this plugin where the
config.yml
is and let it work from there?