Tim Koopman

It's because esbuild is checking for __esModule at runtime and rollup is not. So it will happen to any library that has an entry point with ``` module.exports = require("./something");...

Unsurprisingly, it's a known issue mentioned in https://github.com/rollup/plugins/issues/481 but it doesn't seem like there will be a solution very soon. One thing to note is that the node behaviour is...

After looking into this some more, I think vite should switch to behave the same as rollup. That way it would be consistent with how node works (and snowpack as...

So I already changed my mind again, since changing the dev behaviour will still break dependencies. So, the best case would still be that it gets fixed in rollup. I...

From our production website. Server rendered with some partially hydrated components. Page 1:  Page 2: 

This would also help with unicode urls, since they get urlencoded and are thus completely unreadable.

You can use a [credential_process](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html). Advantage is that caching is up to the configured helper, so no need to do anything at the application level. I'm not sure if the...

Yes, the propTypes are assigned to the wrong class in this case. I have a fix ready, but it still needs to be tested.

Some packages override the React types with non null declarations. I assume those will support `null` just fine because it seems like they would be mostly passing thing trough, but...

They are not unrelated, those are all fixes for incompatible interfaces: ``` Error in carbon-components-react Error: /home/runner/work/DefinitelyTyped/DefinitelyTyped/types/carbon-components-react/lib/components/Button/Button.d.ts:53:18 ERROR: 53:18 expect [email protected] compile error: Interface 'ButtonDefaultProps' cannot simultaneously extend types 'ButtonBaseProps'...