Closed kevinpijning closed 1 year ago
Thanks. From the first looks at this the PR seems pretty complicated. I don't think we need those dedicated configuration loader classes. Can't we just move that logic into the place where it's used?
Can you also undo all code style changes and remove things we don't use like declare strict so the PR is focused at what it's trying to solve? Thanks!
Thanks. From the first looks at this the PR seems pretty complicated. I don't think we need those dedicated configuration loader classes. Can't we just move that logic into the place where it's used?
Sure, i will work something out! What do you think about using the Http client? To much or fine?
Can you also undo all code style changes and remove things we don't use like declare strict so the PR is focused at what it's trying to solve? Thanks!
On it
Let's try without the HTTP client for now if that's possible.
I simplified the code a lot. This is actually the code i started with, but over-engineered it in the end.
The only thing i don't feel comfortable about is testing the remote json file_get_contents
in the testsuite.
Do you think it's fine like this or do you have another idea about how to solve this without using the Http client?
Implemented a driver system for fetching remote configs and also reworked the current logic to also work as a driver
Fixes #200
TLDR;
./vendor/bin/pint --config https://raw.githubusercontent.com/laravel/pint/main/pint.json
The issue
I manage a lot of Laravel projects, and i want my codestyle to be consistent between all apps, but i don't want yet another package to manage.
The solution
Making it possible to allow for remote
pint.json
files and add this pint command to the composer scriptsThis way i can easily manage a single
pint.json
file, on a remote like Github without having to manage a self-created package.