I don't call myself a JS pro. With that in mind, I have never seen somebody export an arrow function using let or var keywords. 100% of examples or real-world code repos that I have seen use const keyword when it comes to exporting a named arrow function.
If that's the global case, then can we not use it?
Instead of:
export const someFunction = () => {}
Can we write:
export someFunction = () => {}
No, that's not worth changing the language for.
(Also, you're mistaken, many people use let exports of arrows.)
Not using const and using var or let has a functionality: overriding a function inside branching.
let someFunction;
if (thisThing) someFunction = ()=> thisReturn;
else someFunction = ()=> thatReturn;
Another option is to consider the absence of const as const.
Why it's not worth it? Any reduction in boilerplate is worth it. No doubt about that.
And it's not unusual. Convention over configuration. When nothing is specific, by convention it means const. If otherwise is expected, the keyword would be specified.
One way is to count the total exports of the entire codebase existing on the planet right now, which is impossible of course. But if we assume that more than 85% of named exports are like export const, then it is worth it.
Let's call it polymorphism. It's not as common as simple constant functions. We can still use convention for the majority of the code.
No. Consistency and clarity is more important than minimizing the number of characters typed.
Is this other option suggesting that any time we omit "let"/"const", treat it the same as a const declaration, regardless of if we're declaring a function or exporting, etc? Putting aside grammar ambiguity issues, there's other problems with this sort of thing.
I used to love how Python was designed so that it didn't require a keyword to declare a variable, such as "let". You just assign to a variable, and if it didn't exist, it would be made.
Something I didn't like in Python was how, when you wanted to modify a variable outside of a function, you had to put "global yourVar" at the top of the function.
Sometimes later I connected the dots and realized that the two went hand and hand - if you don't tell Python when you are declaring vs just assigning, then it has no way of knowing if you want a variable assignment in your function to behave like a separate declaration, shadowing what was in the outer scope, or if it should modify the outer variable. So unless you tell it otherwise, it just assumes, sometimes incorrectly, that you were wanting to shadow the outer scope variable, which can lead to odd bugs.
Convention over configuration is one school of thought, but it isn't always the best choice - if you have to introduce oddly specific rules (such as "you can only leave off const when exporting an arrow function) or if it leads to potentially incorrect assumptions (like Python), then perhaps the school of thought is not the best option here. Boilerplate tends to have a negative connotation associated with it, but some amount of boilerplate can sometimes be a good thing.
When with fewer characters we can get the same level of clarity, then it's fine. Compare these two words:
export const someFunction = () => {}
export someFunction = () => {}
If we know that omitting the const means const then both are as clear and consistent as each other.
Not everywhere. Just when we want to export a function.
Clear is when you don't know but can tell. And whether or not you know has no bearing on consistency. Having consistency can help with clarity, but unfortunately here, consistency is not something we have.
Assignments without declarations generally have one of two outcomes: they assign to a global or throw an error. Either could happen with the function assignment without the export:
someFunction = () => {}
In sloppy mode if not already a global, a new, non-const global is created (configurable property on the global object). Should a declaration for such an assignment allowed to be omitted in a strict module, having consistency would direct us to think this assignment would be similar: not a const, and possibly even creating a global. The addition of export could steer us away from the global aspect but there's still nothing suggestive of it becoming const given the pre-existing sloppy mode behavior.
To add to that, if this is only being done for arrow functions, that would mean more inconsistency since it working or not would be dependent on the value of the RHS expression. Notably this is not a named arrow function. Arrow functions are always anonymous. The name would be coming from the variable (presumably) being declared. The arrow function is a value used to initialize it with.
So in this case I would agree that being explicit makes more sense. I don't think I would assume the binding to be const if it were omitted.