Daniel Cousens

Relevant typescript https://github.com/clauderic/dnd-kit/blob/3abe4f13a3db7c3c8257a7175728cf9a8e1d577c/packages/core/src/sensors/types.ts#L76-L87 See line 85 ```typescript sensor: Sensor; ``` Cannot be satisfied when `T` is **not** refined to `extend Object`. > (type parameter) T in type SensorDescriptor > Type...

Fixed in https://github.com/JedWatson/classnames/pull/281

@9001-Sols the change itself is non-controversial, but, I don't understand what you mean by > causes SSR frameworks to breakdown The `window.classNames =` branch should never come to pass -...

Benchmark output from today ``` Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0 * local#strings x 10,290,716 ops/sec ±1.33% (67 runs sampled) * npm#strings x 10,321,700 ops/sec ±1.40% (67 runs sampled)...

Merged in https://github.com/JedWatson/classnames/pull/281, with the typical usage performance problems resolved

Running the benchmarks in browser and node Node ``` * local/dedupe#strings x 1,823,058 ops/sec ±0.61% (95 runs sampled) * npm/dedupe#strings x 2,021,462 ops/sec ±0.96% (94 runs sampled) * local/dedupe#object x...

I think hyperscript might be out of scope for this library

IMHO NACK, extending the project is very easy by just using `eslint` yourself...

> but it won't be JavaScript Standard Style any more! And neither will this extended version. **One JavaScript Style Guide to Rule Them All** Extensions aren't compatible with that idea....

I'm not against the idea, provided the following was in place: > provide library-specific official Standard rules ("standard-extension-ava", "standard-extension-node", etc.) do not override any of the rules currently in Standard...