Maël Nison

Yep I understand, but unfortunately I don't have a good answer; I don't think we could change that easily 🤔 Note that even on typical file systems you may be...

> No, due [#12483 (comment)](https://github.com/webpack/webpack/issues/12483#issuecomment-767034297) @alexander-akai Note that what I mentioned should still be a valid workaround. I understand you'd prefer to do as little IO as possible, but in...

Hm but that doesn't solve the issue for interactive elements, right? For example, if we imagine a list of radio buttons, the ones beyond the top of the screen would...

> Maybe what @arcanis means here is something of a general purpose scrolling component that can wrap any number of components as children and allow scrolling through it. I tried...

Another option is to make a decorator. It's more verbose than the first alternative, but you only pay the price once: ```ts function ReferenceField(returnTypeFunction: any, opts?: FieldOptions) { return (target:...

> Just check the `d.ts` files for proper typings for `ReferenceField` params, as `any` smells 😅 Yeah I agree, but parameter forwarding is annoying with TS - especially since `ReturnTypeFunc`...

Oh for sure, hardcoding `load()` isn't the right way - the snippet I shared: ```ts const ReferenceField = (returnTypeFunction, opts) => Field(returnTypeFunction, {...opts, get: ref => ref.load()}); ``` wasn't meant...

That would be neat, especially since each team could bake their public key in Corepack 🤔 However, while we could sign the Yarn 2 releases by writing an header comment...

Now that I think about it, now that the cache and the node_modules are effectively the same, the results aren't as easy to interpret 🤔 Hmm maybe the "n/a" approach...

I'll restore the n/a, use a different color for Yarn 2.x, add the "1.x" label to the column, and maybe sort the table so that all the "caches" / "no...