Attila Beregszaszi

The current logic is very simplistic indeed, the total number of items are evenly divided. The sole reason for this behaviour is that the dimensions of grid elements cannot be...

Thanks for this I think it looks good. Even though it still cannot solve the problem of potential initial layout repaints with images or iframes, I would certainly consider this...

I shall keep this open for future reference but I cannot dedicate much time to implement new features on this right now. I guess we'd need to update the tooling...

Yes, that change in #2211 now triggers a full build on all our 100+ workspaces every time anything changes in package-lock.json in the root, regardless of relevance. The naive approach...

It definitely is an issue with `1.6.3` on npm, while I don't recall this on versions prior to 1.6.x. Any change to package-lock.json triggers all jobs on all workspaces 😮

I have configured all our turbo commands to use a dedicated cache folder outside node_modules, e.g. `--cache-dir=./.turbo-cache`. I wish it was configurable via environment variables but still easy to work...

I've tried the workaround at https://github.com/cypress-io/cypress/issues/26203#issuecomment-1571861397 but my problem is that `cypress/tsconfig.json` is ignored. If I set sourceMap to false in the tsconfig.json of the workspace, it works fine. The...

This definitely is missing from tsconfig-paths. We have a slightly different use case where base tsconfigs are not in the monorepo root but in a package called tsconfig, so extends...

Do you have a jsfiddle where the issue can reproduced?

@yarinsa it looks great but ideally this logic should be supported on all lockfiles, not only yarn. We for example just use npm workspaces so package-lock.json support would be desirable...