From a Python developer point of view, design is a bit surprising - why isn't it created as two separate libraries:
1) csv writer (and reader?) which takes care of all csv dialects crazyness;
2) a library which "flattens" nested objects/arrays?
(1) is not opinionated (besides a few API choices), it just has to be correct; it doesn't make much sense to re-implement (1) everywhere.
(2) can be more opinionated, it is easy to disagree with design choices, there is more room for personal preferences.
For example, in Python there is CSV stdlib module, and for (2) there are libraries like https://github.com/scrapinghub/flatson. Why put both to the same library? Is it something ideomatic in node.js world, with a deeper reason to design libraries this way (e.g. download size), or is it just an oversight?
Comments
From a Python developer point of view, design is a bit surprising - why isn't it created as two separate libraries:
1) csv writer (and reader?) which takes care of all csv dialects crazyness; 2) a library which "flattens" nested objects/arrays?
(1) is not opinionated (besides a few API choices), it just has to be correct; it doesn't make much sense to re-implement (1) everywhere.
(2) can be more opinionated, it is easy to disagree with design choices, there is more room for personal preferences.
For example, in Python there is CSV stdlib module, and for (2) there are libraries like https://github.com/scrapinghub/flatson. Why put both to the same library? Is it something ideomatic in node.js world, with a deeper reason to design libraries this way (e.g. download size), or is it just an oversight?
It could be. The question is: why should it be?
Everything you said makes sense if those are the goals, but if they aren't... well, why should they be?
The design you suggest would be done by some module authors for sure, but there's no reason it needs to be that design.