silverwind

I do prefer GitHub's way because a "resolved" issue is still closed, so state (open/close) should remain a boolean, which also makes APIs easier to consume and more importantly not...

What we display in UI vs. what we store in DB can be different. For DB I suggest: `isClosed`: true | false (unchanged) `issueState`: "completed" | "notPlanned" UI could show...

There are at least 4 typescript compilers in existance: esbuild, swc, tsc, and soon tsgo/corsa. I don't think webpack should tie itself to any of them, just let them be...

Ah yes, webpack has parsing needs, of course. Best performance would be to only parse once and then use the resulting AST for everything, bundling, type-stripping, minification. I guess it...

How about making it a single rule `no-deprecated` instead of splitting into multiple rules? I guess I prefer to rather have one rule than many, and this is also how...

Yeah, I can live with three rules instead of one. I see that it fits the naming scheme. By the way, user-defined deprecations in CSS via comments could be considered...

> v3.5.1 You meant v4.5.1?

FYI, `arrayMove` is now in `@dnd-kit/helpers`: https://github.com/clauderic/dnd-kit/blob/2c4b739adc892d04ccbdd23a54641078ada8bb7d/packages/helpers/src/move.ts#L12

> For full_bin, I will also deprecate it, but in the next PR, I will put envs in a new field. Will running commands like `make` be supported once `full_bin`...

Ah I see, `entrypoint` also accepts "path-resolved tools", so yeah that will work. It wasn't clear when looking at [this](https://github.com/air-verse/air/blob/a8f644ca6547e9f04870570377614beb428ed6e6/air_example.toml#L19-L20), but I see it's documented in `README`.