Fix potential inherited prototype chain issue

[oliviertassinari]

• I was hit by this issue integrating Preact with Material-UI.
• It's an encouraged pattern by Eslint: https://eslint.org/docs/rules/guard-for-in#require-guarding-for-in-guard-for-in.
• Could it be preact-compat doing something strange? https://github.com/developit/preact-compat/blob/master/src/index.js#L46.

What would you like to add/fix?

name equals $$typeof in this fail.

[HenriBeck]

But why would a vnode get used as a plugin? 🤔

[HenriBeck]

About the slow commit: I think we should run most checks in the CI and not allow merging without a passing build (though this is currently because external contributors build will always fail and browser stack often timeouts)

[oliviertassinari]

@HenriBeck This is an excellent question. I haven't looked at why. I have assumed that the JSS should only take the plugin own properties and ignore the prototype chain.

[developit]

This is a result of importing preact-compat against preact@10. The two are incompatible, but instead of throwing an error, preact-compat will actually decorate Object.prototype with a bunch of stuff.

(the reason is because preact-compat tries to install properties on the VNode class used by preact 8.x, and it does so by doing: Object.defineProperties(h('a').constructor, ...) - however, in Preact 10+, h('a').constructor === Object)

[oliviertassinari]

I confirm that it works perfectly with preact/compat. I'm closing the pull request. It's too time-consuming to make it pass :).

[oliviertassinari]

@developit Thank you!

[developit]

Thank you for bringing this back to our attention! We've just published an update to preact-compat that should make it warn when installing alongside Preact 10+.