Nit: naming, maybe includeNodeBuild? (so it doesn't sound like you're configuring the build to be for node specifically)

Done

All things equal, if a user didn't explicitly load the dom-shim, it'd be nice to keep as much as possible off the global. I think we could pull HTMLElement into a local variable (and shim it there) rather than put it on the global, right?

customElements is a little harder; we could do the same in the decorator, and that would just leave JS users to needing to do customElements?.define(...) in their own elements. But maybe it's worth keeping customElements on the global to help smooth that over?

Agreed. I think if this approach is good it's exactly because it 1) puts all the cost on the node import, so 2) can go to extra lengths to isolate any shims to just this module.

I think we should be able to do something like:

const HTMLElementShim = class HTMLElement { ... }
export class ReactiveElement extends (NODE ? HTMLElementShim : HTMLElement) {

Regarding window.customElements, shouldn't that be shimmed, if at all, in the decorator definition module? And there we just need the decorator to not access it, yeah?

Let's sync on this offline. It seems like Al is moving towards not having a DOM shim separate from 'lit is loaded in Node'? If that' the case, we do want to populate the global in the Node import condition, yeah?

As per meeting this morning, HTMLElement is no longer globally shimmed, it is instead just declared inline. The reason we don't need HTMLElement globally is that we're only concerned with users who are extending ReactiveElement or LitElement.

I have kept the global customElements definitions so that it will be possible to import components that aren't defined using the decorator.

Just pushed another change that shims HTMLElement in a slightly more sneaky way. It now temporarily defines globalThis.HTMLElement, and then removes it after ReactiveElement is defined, instead of changing the extends clause at all.

The reason for this is that I found that the following code ... :

export abstract class ReactiveElement
  extends (NODE_MODE && global.HTMLElement === undefined
    ? (class HTMLElement {} as unknown as typeof HTMLElement)
    : HTMLElement)

... resulted in in this d.ts output:

declare const ReactiveElement_base: {
    new (): HTMLElement;
    prototype: HTMLElement;
};
/**
 * Base element class which manages element properties and attributes. When
 * properties change, the `update` method is asynchronously called. This method
 * should be supplied by subclassers to render updates as desired.
 * @noInheritDoc
 */
export declare abstract class ReactiveElement extends ReactiveElement_base implements ReactiveControllerHost {

Which, for some reason, causes ts-transformers to fail with this error:

        --··"../reactive-element/reactive-element.d.ts(181,55):·error·TS2749:·'ReactiveElement_base'·refers·to·a·value,·but·is·being·used·as·a·type·here.·Did·you·mean·'typeof·ReactiveElement_base'?\n",

I also have a suspicion that the ternary extends could be upsetting to Closure compiler.

Open to other suggestions, but this approach of defining and then undefining it should be the least confusing to type systems.

I can't think of any better way. I tried playing around with it a bit but TS also did not like an exported class extending something that's module scoped.

Make sense to include a version that doesn't use the decorator as well?

Done

Is HTMLSlotElement going to be defined in Node? Is that in the dom-shim? And what about all the other element classes? Users probably won't use ?. for these as is done here, right?

No, and the broader DOM shim doesn't define HTMLSlotElement either. Somebody could be doing e.g. instanceof HTMLSlotElement somewhere, but I think we don't need to worry about it for now.

Add a version that doesn't use the decorator?

Done

Let's sync on this offline. It seems like Al is moving towards not having a DOM shim separate from 'lit is loaded in Node'? If that' the case, we do want to populate the global in the Node import condition, yeah?

Ooh very nice utilization of capture groups.