gcanti / tcomb

Type checking and DDD for JavaScript
MIT License
1.89k stars 120 forks source link

Formatting {readable: true} improvement? #331

Open fatso83 opened 5 years ago

fatso83 commented 5 years ago

Basically, is there a way we can get error output that is more easily digestible by a human? My team generally finds tcomb nice to use, but the number one complain is that it is hard to find what is going on. Where is the error in the loooong string? Could there perhaps be some sort of indented output, the way React does it?

Version 3.2.23

Expected behaviour

An error should have a format that is easily parsable by a human being

Actual behaviour

An error produces an output only a machine parser could love

Steps to reproduce

  1. Create some nested types
  2. Make a validation fail
  3. Try to find out where the error happened

Stack trace and console log

This example is pretty OK (it's not nested), but it still shows how you need to start at the end and work your way backwards.

TypeError: [tcomb] Invalid value 1234 supplied to Struct{_id: Integer | String, nationalId: String, age: ?Number, gender: {String | <function1>}, firstName: String, lastName: String}/firstName: String
    at Function.fail (node_modules/tcomb/lib/fail.js:2:9)
    at assert (node_modules/tcomb/lib/assert.js:14:12)
    at Irreducible (node_modules/tcomb/lib/irreducible.js:18:7)
    at create (node_modules/tcomb/lib/create.js:9:104)
    at new Struct (node_modules/tcomb/lib/struct.js:82:19)
    at Struct (node_modules/tcomb/lib/struct.js:71:14)
    at createPatient (tests/stub-object-helpers.js:67:10)
    at createDefaultProps (tests/components/ViewEncounterScreen.test.js:31:23)
    at Context.<anonymous> (tests/components/ViewEncounterScreen.test.js:25:72)