-
Notifications
You must be signed in to change notification settings - Fork 438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Resolve dist file path from import #1134
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this issue!
This change requires an additional E2E unit test to make sure it works and will keep on working as expected.
use Symfony\Component\Config\Loader\LoaderInterface; | ||
use Symfony\Component\Config\Loader\LoaderResolverInterface; | ||
|
||
/** | ||
* A decorating dist loader that supports **.dist files and defers loading. | ||
*/ | ||
final class DistFileLoader implements LoaderInterface | ||
final class DistFileLoader extends FileLoader implements LoaderInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused on why this solves your issue:
The idea of this class is to be a decorator around another loader.
Every public method inside this decorator proxies to the wrapped loader.
So how does extending the FileLoader helps solving the problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory I'm not sure and you're right. In practice does this help, because the path to the .dist file is now resolved. Where the resolving didn't happen before.
I didn't take a deep dive into more code. I've added some var_dumps in all the load functions (from this DistFileLoader and the YamlFileLoader). Without the 'extend' the load function was presented with an unresolved path. With the 'extend' it was presented with a resolved path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition... if you think this is not the correct way, no probs. It resolved the issue for me. But yeah, there might be a better way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably one of the abstract FileLoader public methods is fixing the issue for you for some specific reason.
However I've got the feeling there should be a better fix indeed but haven't touched those classes in a long while so don't know without diving into it.
One thing I could think of, is that the import falls in this scenario which makes it fail:
grumphp/src/Configuration/Loader/DistFileLoader.php
Lines 35 to 37 in 16431b6
if ($type !== null) { | |
return $this->loader->supports($resource, $type); | |
} |
@veewee I've found a solution without extending like you suggested. The I've added the project root directory here which fixes the issue. EDIT: Better phrased. When grumphp is triggered it uses a path to the configuration file |
Thanks for looking into it @mischabraam. Can you also add an E2E test to cover this specific case? |
EDIT: nvm found it |
@veewee I've added an E2E test.
No, adding this path enables you to use relative paths from the project root dir. So, the following works (verified this).
|
@mischabraam looks good thanks! I do note that you mention 'project root dir' a few times. See:
Figuring out what the project root dir is a process that takes op to 2 iterations. Currently this PR only adds the path of the config file, and not the project root dir persé. (it could be the same path though). But now I'm wondering : is this correct and "enough" ? Another approach might be to provide the |
Yeah, you're right. In my projects, the grumphp.yml file is in the root dir. But yeah, I mean the path from the config file. That's the reason why I called the variable |
Its probably sufficient for now. |
v2.x