silverwind

Keep in mind that Node.js is currently violating the spec for the `%d` specifier where it uses the `Number` constructor which outputs those undesired scientific prefixes. The specced `parseInt` on...

Actually upon deeper investigation `parseInt` is also unsuitable for BigInt because it has [NumberToString](https://tc39.github.io/ecma262/#sec-tostring-applied-to-the-number-type) baked into it which represents everything above `1e21` using exponents. So I think we'd actually need...

> Also the third column of https://console.spec.whatwg.org/#formatting-specifiers should be updated Maybe add a additional column before it for the source type. This could also include the Symbol special case.

The Chrome implementation appends the `n` suffix to the formatted number but I think it would be more generally useful to hide such implementation details and output just the number.

That example includes a path-based import which would break when the referenced file is moved. I would not consider it a stable interface.

Seen the same error in a component that uses both `useDrag` and `useDrop`. The error certainly seems to be related to the `collect` function. Once I remove both my `collect`...

Just wondering why this fix hasn't propagated to npm yet. Is it because `npm/cli` depends on `pacote@8`?

This is actually a bad idea, at least with [stylus](https://github.com/openstyles/stylus) which parsers those `@-moz-document` into site-specific blocks and applies the contained styles on all browsers, not just Firefox.

`@-moz-document` is stripped entirely from the resulting style. What remains can and should be prefixed for all browsers.

Just unwrap to my understanding. Every body of a `@-moz-document` is put into its own "section" which finally results in a `` tag being added to the document for each...