3 ms·

Sure, this discussion is full of options, but none are really perfect, so there are plenty of opportunities for bikeshedding!

by pas 7y ago

eyelidlessness 7y ago
I guess you could call trying to offer a helpful suggestion bike shedding ¯\_(ツ)_/¯
- pas 7y ago
  Excuse me if I have offended you, my intent was rather far from that. The bike-shedding is to which one to pick right now, when there doesn't seem to be a clear superior choice. I saw your suggestion as just as a bit half-baked as the ad-hoc stuff I actually use now, and the other in-chimings in the discussion. (io-ts, utility-types, runtypes, etc. all are great, but as the title indicates it feels there should be one schema system specifically designed for TS. That can be used for description and validation of all interfaces of a TS system, including incoming requests, static and runtime configuration, outgoing data, and mapping these to internal domain modeling.)
  - eyelidlessness 7y ago
    > Excuse me if I have offended you, my intent was rather far from that. > > The bike-shedding is to which one to pick right now, when there doesn't seem to be a clear superior choice. Fair enough. My intent was not bike shedding, but just mentioning a thing that exists if you would like to use it. In my experience most people are not aware `config` supports TypeScript config files. > I saw your suggestion as just as a bit half-baked as the ad-hoc stuff I actually use now, and the other in-chimings in the discussion. For what it's worth, for libraries which require config I combine io-ts (well my wrapper around it) for validation and the types it generates for type safety. It is not an experience that feels half-baked to me. It guarantees that clients using my libraries provide valid configuration at runtime, and allows them to get static guarantees of the same (which I also employ in clients which use those libraries). > (io-ts, utility-types, runtypes, etc. all are great, but as the title indicates it feels there should be one schema system specifically designed for TS. That can be used for description and validation of all interfaces of a TS system, including incoming requests, static and runtime configuration, outgoing data, and mapping these to internal domain modeling.) IMO there doesn't need to be just one, as long as people can find one that suits their needs. I certainly use io-ts for all of the things you describe, it is designed specifically for TS, and I am quite happy with it.

Sure, this discussion is full of options, but none are really perfect, so there are plenty of opportunities for bikeshedding!

by pas 7y ago

Sure, this discussion is full of options, but none are really perfect, so there are plenty of opportunities for bikeshedding!

eyelidlessness 7y ago

I guess you could call trying to offer a helpful suggestion bike shedding ¯\_(ツ)_/¯

pas 7y ago
Excuse me if I have offended you, my intent was rather far from that. The bike-shedding is to which one to pick right now, when there doesn't seem to be a clear superior choice. I saw your suggestion as just as a bit half-baked as the ad-hoc stuff I actually use now, and the other in-chimings in the discussion. (io-ts, utility-types, runtypes, etc. all are great, but as the title indicates it feels there should be one schema system specifically designed for TS. That can be used for description and validation of all interfaces of a TS system, including incoming requests, static and runtime configuration, outgoing data, and mapping these to internal domain modeling.)
- eyelidlessness 7y ago
  > Excuse me if I have offended you, my intent was rather far from that. > > The bike-shedding is to which one to pick right now, when there doesn't seem to be a clear superior choice. Fair enough. My intent was not bike shedding, but just mentioning a thing that exists if you would like to use it. In my experience most people are not aware `config` supports TypeScript config files. > I saw your suggestion as just as a bit half-baked as the ad-hoc stuff I actually use now, and the other in-chimings in the discussion. For what it's worth, for libraries which require config I combine io-ts (well my wrapper around it) for validation and the types it generates for type safety. It is not an experience that feels half-baked to me. It guarantees that clients using my libraries provide valid configuration at runtime, and allows them to get static guarantees of the same (which I also employ in clients which use those libraries). > (io-ts, utility-types, runtypes, etc. all are great, but as the title indicates it feels there should be one schema system specifically designed for TS. That can be used for description and validation of all interfaces of a TS system, including incoming requests, static and runtime configuration, outgoing data, and mapping these to internal domain modeling.) IMO there doesn't need to be just one, as long as people can find one that suits their needs. I certainly use io-ts for all of the things you describe, it is designed specifically for TS, and I am quite happy with it.