Update package dependency version for kint-php/kint

[Martin-4Spaces]

It would be nice if the composer.json file could be updated with kint-php/kint 3.2 instead of
2.1.
2.1 is kind of old (2017) and I am having conflicts with other composer packages depending on kint 3.2 :)
Ty!

[MGatner]

Good suggestion. We'll have to test it first but I think this would be good to do before release.

[lonnieezell]

The new version of Kint does not make our requirements any easier. lol

Since we have a vocal segment that doesn't like Composer and just wants to download the zip of the framework we've previously copied the file to ThirdParty and used that file so that it's always available. Well, in 3.x Kint is more mature and complex. The worst offender currently is that it tells composer to load it's init file automatically so getting a working system that works both ways is proving a little tricky. I'll work on it some more tomorrow, hopefully.

[musmanikram]

@lonnieezell i don't know what you are meant by vocal segment.
But i tried to update kint version, please have a look on this PR: #2542

[najdanovicivan]

@lonnieezell I've added two possible options for handling this one properly.

Option one is to obtain kint from git repo requiring modification of commit hash for each update.

The second one builds kint locally. It requires changing the ini configuration but it avoids versioning issues with commit hashes

IMO I like the second one better.

[MGatner]

@najdanovicivan that's some nice work on those! Thanks for taking the time.

[lonnieezell]

@najdanovicivan what type of "building" with Kint is required? We don't necessarily need the phar file, I don't think. Of the top of my head, that's likely my preferred way to, but need a little more info, please.

[lonnieezell]

@najdanovicivan @MGatner I would love it if you guys could pull down PR #2564 and give it a spin.

I think it works, and makes it possible to use without a phar file, since I really don't like the idea of requiring every dev to modify the php.ini to allow phars to not be read-only. That sounds like a dangerous setting I'd rather not force.

[najdanovicivan]

@lonnieezell I gave it some thought over the weekend how to avoid compiling phar. I see you've already came to the similar solution but my idea is bit different. Check out #2565. I've submitted this one to Your kint3 branch.

The way You did it makes script always ignore composer files and load Kint from ThirdPary. On the other hand the solution I've posted will load the Kint from composer first and if it does not exist there it will load it from ThirdParty folder

It also fixes and issue when Kint is being used with environment other than development.

[lonnieezell]

@najdanovicivan Nice touches. I've merged those into the kint3 branch.

[najdanovicivan]

@lonnieezell Great. Now we just need to define which of the options to add to the config file. There's a lot of options available in Kint.

Kint.php has a lot of option, 4 types of rendered RICH, TEXT, CLI, PLAIN and each having it's own options. It will be good to use CLI mode for CLI but adding all of those to config file does not make sense.

It might be a better solution to have separate config file for Kint and just require it after loading kint as all of those parameters are static and can be directly set on the Kint classes and subclasses

PS. I'm gonna close those PRs I've submitted previously as this is most definitely the best way to go.

[lonnieezell]

Yes, I thought bringing them out to their own config file would be a good idea, too. I don't know that every single option needs to be available here, though, just the ones most likely to be changed. Those can always be expanded at a later date, though.