search

kint-php / kint

Kint - Advanced PHP dumper
https://kint-php.github.io/kint/
MIT License
2.78k stars 292 forks source link

pull request? #205

Closed voku closed 8 years ago

voku commented 8 years ago

Hi,

I forked this repository and made some changes, too much changes. So I don't know should I create a pull request ... maybe into a new developer-branch (2.x)?

https://github.com/voku/kint

jnvsor commented 8 years ago

I've got a large "Gut the whole thing" RFC of my own in the works that might be combined with some of your stuff. Notably you can get far more meaningful unit tests out of it since the parser and renderers are properly decoupled.

But looking at yours it seems to have gotten very complicated all of a sudden. I've never even heard of half the badges at the top of your readme (That's either very good or very bad :P)

There's something to be said for installing with nothing but an include too. To quote the readme:

One of the main goals of Kint is to be zero setup. Download the archive and simply

<?php
require '/kint/Kint.class.php';
raveren commented 8 years ago

I've kept an eye on your work previously, but I'm afraid this has little chance of getting merged, as @jnvsor notes, your changes contradict the main principle of Kint as well as multiple others; here's an exert from my contribution guidelines, sorry for not yet publishing them:

Goals

When expanding Kint, keep in mind its main priorities:

  1. Maximum PHP version range compatibility: Kint supports and must continue to work down to at least PHP 5.1 and support all latest stable PHP features and additions as soon as they are released
  2. Ease of use: developers must be able to install Kint effortlessly and start using it immediately with no additional required steps. It should also provide flexible and simple to use configuration when the user feels confident enough. Through configuration Kint should be able to adapt to popular workflow scenarios.
  3. No feature creep: requests for edge use cases, especially ones that can be worked around with some configuration, should not be catered to. The definition of edge case is the popularity of the feature request, if it's popular - it's a workflow, if not - it might be an edge case.
  4. Do not compromise information clarity: displaying relevant information and not omitting meaningful data takes precedence over every principle in this list - as well as (and not limited to) performance and tidy Kint codebase.
  5. Code quality: the nature of Kint implies that it will be continued to develop for many years - at least to adapt to new language features and quirks. Keep the codebase as maintainable as possible.
  6. Stable releases: never publish versions that are not thoroughly tested to the master branch. Due to the nature of this project, any kind of meaningful test coverage is mostly impossible and because it is a development tool, people may leave their composer require-dev Kint configuration to allow auto-updates.

Having said that, I really like what you did with the SCSS migration, I'll try it out, if it's definitely easier to work with than LESS (compilation is stone age, I've been looking for an alternative), I'll adopt it and credit you for the implementation.

Thanks for all of your work, I bet it was amazing fun to do it, but unfortunately it will have to continue as a separate fork if you want to support it.

raveren commented 8 years ago

I've published the finished parts of contribution guidelines

https://github.com/raveren/kint/blob/master/CONTRIBUTING.md

voku commented 8 years ago

No problem, I didn't saw that this project still supports PHP 5.1.0 ... coding is poetry and yes it makes me amazing fun! :)

raveren commented 8 years ago

I'm so happy you feel that way, thanks so much for your input, I'm already linking grunt, I can use closure compiler as well as css minimization, that's great!

jnvsor commented 8 years ago

Yeah, grunt or gulp are the main frontend build systems.

@voku I confess, my work also runs afoul of the 5.1 dependency (But meets all the others at 5.3 and makes it plausibly testable!)

Since it’s unlikely to be accepted wholesale, would @voku like to colab with me on making a proper fork?

Some of the changes could be worked back into kint over time too

Edit: Scratch that, I may be able to get it working in 5.1 after all

Edit 2: Way after the fact and possibly irrelevant but I'm going to note it anyway: Scratch grunt and gulp - since all we really need is sass and JS compilation just using plain old npm and it's scripts will be far simpler and cleaner. I might make a PR some time