search

inspect-js / object-inspect

string representations of objects in node and the browser
MIT License
142 stars 36 forks source link

Add API for a custom list formatter #10

Closed mk-pmb closed 7 years ago

mk-pmb commented 7 years ago

With this feature I hope I'll be able to format my dumps with custom indentation, maxArrayLength and breakLength. Edit: Nah, put it on hold, I'll implement an even better version tomorrow. Edit: done.

ljharb commented 7 years ago

I'm not sure I understand the use case - but regardless, the tests (that don't have your option provided) must not change, otherwise it's a breaking change.

mk-pmb commented 7 years ago

I've reverted the version bump as requested, and will move the whitespace cleanup to its own PR. My use case is a data comparison module, where my current approach is to inspect() the data and then diff the resulting text lines. The diff would be much clearer if there were only one value per line. It's easy with .breakLength in node v6 util, but I'd like to have it work in browsers as well. I think the increased consistency in how containers are displayed is worth breaking change.

mk-pmb commented 7 years ago

The new version has the better API that I announced I'd implement today: Type and size are now separate, and it even gets a reference to the original object so I could display prototypes (Object vs. null) if I wanted to. I managed to even replicate all the old oddities so tests don't have to change and semver jump could probably be at just patch.

mk-pmb commented 7 years ago

New version with the EOL whitespace preserved as per #11.

mk-pmb commented 7 years ago

Thanks for your comments! Maybe someone might fix them and see whether it might then land in master. My own motivation for sharing my new feature is used up though, so I'll just fork it and use it as I see fit.

ljharb commented 7 years ago

@mk-pmb adding a new feature requires eternal maintenance, so if you don't have the energy/motivation to make it through a mild code review, it's pretty clear that you won't be around long term to help maintain it either, which generally means it's a bad idea to add the feature.

Thanks for the contribution - if you change your mind, I'm happy to reopen this.

mk-pmb commented 7 years ago

You're right, the maintainance perspective is another good argument to go separate routes from here, as I won't re-configure my editor to preserve EOL space any time soon. ;-)