Recommending export {} maybe not so good?

[ljharb]

The text says "should specify an export {} to make their intentions clear and avoid accidental parse errors while removing import statements.". If you're simply saying "should specify any export" then I agree with that - but I'd think exporting a mutable object is a dangerous casual API to create, whereas export default null or export default undefined is safe.

Could we change the text to recommend export default undefined?

[jmm]

@ljharb That was my suggestion (originally in nodejs/node-eps#3 (comment)). It's not supposed to export an object (or anything). From what I've been able to tell, export {} (export ExportClause with no ExportsList) is a no-op syntax that's valid per the spec (though I'm not sure why it was included). If that's correct it's a way to include an export declaration that satisfies the requirement proposed here without actually exporting anything.

See also #3.

[ljharb]

aha, good call. You're right that export {} is just zero named exports, so that's actually better than exporting a default of null/undefined.

[jmm]

Cool, thanks for confirming. Since it may not be clear to a lot of people what that syntax represents, maybe it'd make sense to include a quick note explaining it.

On a side note, what kind of danger did you have in mind if an object had been exported? In general modules are often going to export mutable objects, right? E.g. export default function () {}.

[ljharb]

If an object was exported, people might rely on being able to set and get properties on it, and even if that's common, it's still an uninintended API contract.

[jmm]

Thanks. While it should never be advertised and people shouldn't rely on unadvertised stuff that just happens to be there, I see what you mean. That actually highlights what we all agree on -- that it's better to not export anything at all, as that could be similarly abused (just by importing it when it's never intended for external use and is therefore subject to change at any time).