Should functions be named across `d3-*` ? about d3-format

[mbostock]

It’s a bit obnoxious of tooling to place this burden on library authors in this way, but at any rate, I’ll probably switch everything to use named instead of default exports at some point. It’s not high on my priority list, though, sorry.

[gabrielbahniuk]

It’s a bit obnoxious of tooling to place this burden on library authors in this way, but at any rate, I’ll probably switch everything to use named instead of default exports at some point. It’s not high on my priority list, though, sorry.

@mbostock it was only a question as I am investigating solutions for the problem I have, not placing a burden on anyone, sorry if you understood that way. Thank you for the answer.

[mbostock]

@gabrielbahniuk My comment was directed at Next.js (or maybe React Fast Refresh? wherever the warning comes from). It seems strange that it can’t just assign an arbitrary name like “_default” and make anonymous default exports work out of the box. My objection is that JavaScript provides a standard language feature (default exports) and it’s a shame when tooling doesn’t support the language standard completely, and then the burden is placed on library authors to rewrite their code to satisfy the limitations of popular tooling.

[gabrielbahniuk]

@mbostock oh, i misinterpreted and agree with you - there are a few d3-* packages, but imagine if there were 100+ packages, I would have to change each one because of 1 framework - that doesn't sound right (even though naming functions seem correct, but not for this purpose).

I will continue my investigation and try out other solutions as well.

As a side note: not sure if that would be ok for you but I would be fine to open PRs to replace non-named by named functions in default exports.