davidmarkclements / cute-stack

Cute up your stack traces in Node
82 stars 6 forks source link

2 features: column and tree printer #4

Closed bahmutov closed 9 years ago

bahmutov commented 9 years ago
davidmarkclements commented 9 years ago

very nice!

davidmarkclements commented 9 years ago

If we keep adding plugins, it might make sense at some point to review which plugins should be in core, then break the rest out into separate modules - e.g. cute-stack-tree

bahmutov commented 9 years ago

yeah, this was just something quick I wanted to see if it made sense. Agree that these should be plugins, maybe all except for pretty and json? I would also start looking at ways to integrate it with unit test runners, like mocha or my own gt

How about code linting, unit tests and travis ci build?

gleb

On Thu, Feb 12, 2015 at 6:24 AM, davidmarkclements <notifications@github.com

wrote:

If we keep adding plugins, it might make sense at some point to review which plugins should be in core, then break the rest out into separate modules - e.g. cute-stack-tree

— Reply to this email directly or view it on GitHub https://github.com/davidmarkclements/cute-stack/pull/4#issuecomment-74055958 .

davidmarkclements commented 9 years ago

yah pretty and json in core, rest separate modules - autodetection and loading of plugins would be nice

test runner integration - interesting. For test runners that aren't using Error.prepareStackTrace this would be trivial, ones that are we want to play nice

code linting, unit tests, builds - all good things, however de-prioritize during innovation phase,

1) keeping everything small (e.g. plugins) with working examples is good enough for now 2) in large multi-team projects style is important, I don't see this as a huge code base, rather lots of little pieces, those little pieces are free to have their own style, so the overhead of linting is just drag as far as I'm concerned, for this project 3) builds do have value, particular since we're in a transition phase between node 0.10.x and 0.12.x and also iojs - multiple build targets with a really simplistic test runner which compares actual output with expected output of an example would be fine. but still, let's put this on back burner for time being