Fotis Papadogeorgopoulos

I am pretty sure the CI fails because it's trying to import the ES module from ./css-ns.js rather than dist/css-ns.js

Hi @richiksc, I think this is because the `pruneSource` is `true` by default. I had the same issue, and turning it to `false` fixed it. (The option is documented here:...

I know, I was mentioning it in case it was something actionable; I don't know the things you are building, not pruning could very well have a large effect there...

Hi, @karottenreibe! That sounds frustrating, I imagine getting odd errors like that can be a bad first experience. The issue of Typescript versioning and their various config options has been...

Hi, @eleith! Thanks for getting in touch. `` support has been on my mind recently, and I think it should be possible to implement it. I will give it a...

Hi @ku8ar, it's me out here :D I saw this PR initially, left a note to get back to it, and the summer holiday season came around. Part of what...

Hi @aralroca! Thanks for opening this issue. `loadEagerly` is indeed meant for cases where you want to make it as if the "actual" `img` was always there. For example, it's...

I think the workaround that you mention with `onError` is the best way to handle loadEagerly + error handling at the moment. The second scenario with `loadEagerly={!process.browser}` will have quirks,...

Hi @techwes! Sorry for taking a while to get back to you, it's been a hectic few weeks. Re-enabling the noscript fallback has been on my mind for a while....

Hi @mintaras! Thanks for the report. This issue can come up in a number of ways in React components, and it might depend on the usage. It seems that the...