As discussed in jsdom/jsdom#2770 (comment) I would prefer not to do this.

Well, this is also closer to how ECMAScript modules work.

Until we drop support for Node 10 (in May 2021) and start leveraging ES module, using exports. would greatly help circular dependencies.

I found myself introducing new circular dependency issues when working jsdom/jsdom#2548. There is one interesting case with StorageEvent (code). Adding support for custom elements, forced me to change the modules evaluation order, which had the unexpected effect of exhibiting the circular dependency between Storage and StorageEvent. The circular dependency between the interfaces can't be fixed, because the 2 interfaces depend on each other.

By instead creating data properties on exports and treating it as a constant, then every reference will have all the properties after all modules have been evaluated.

Using exports. instead of module.exports would allow me to move the require statement at the top of the file.

OK. While I still think that we should avoid circular dependencies whenever possible (e.g. we should merge attributes.js and Attr-impl.js), I can understand that the web platform we're implementing is not so cleanly layered, and so perhaps we should allow them in some cases.