Not really. If I'm using a linter, I go and configure the strictest possible ruleset, and only disable rules when justified on a need-by-need basis. It's just a matter of discipline.
I'm currently using niri (was previously using Hyprland).
Having used dwm-like tiling window managers for most of the time, I don't really care for the scrolling or dynamic workspace aspects of niri at all - in fact, I kinda dislike them (or haven't gotten used to them, at least). To me, it kills the point of a keyboard-centric desktop environment - which is the speed and lack of friction in making the window you want appear in front of your eyes.
Despite that, I still really like it. Mostly because I have so much more faith in its development. The documentation is excellent. The configuration file is sane, and not as arcane and ad hoc as the hyprland.conf format. The source repository looks well-maintained. Being written in Rust rather than C++ means onboarding new developers is easier. The discourse is more measured, owing to the lack of a somewhat stubborn lead maintainer in the case of Hyprland.
The surrounding ecosystem seems to be flourishing as well, with projects like Noctalia Shell, DankMaterialShell, and niri-flake natively supporting niri.
And perhaps most importantly, the out-of-the box experience is really nice. You have proper monocle and tabbed layouts without any compromises - features Hyprland has still not developed, where they are only possible with scuffed C++ plugins, or where its BDFL has stated they will never be introduced. Most features one would expect from a WM are already there and well-documented, which can't be said about Hyprland.
"GitHub actions bad" is a valid take - you should reduce your use to a minimum.
"My build failed because of GitHub actions couldn't install a dependency of my build" is a skill issue. Don't use GitHub actions to install a program your build depends on.
No, you really don't have to. Partially complete software can have a lot of value too.
Anyone can fork it and quickly add the i18n (or just translate into a different language) for their own purposes. People will likely want to contribute i18n. People may fix or improve things for you.
Of course, it's entirely up to you - but I've appreciated half-complete software countless times before.
I have the same disagreement. TypeScript with its structural and pseudo-dependent typing, somewhat-functionally disposed language primitives (e.g. first-class functions as values, currying) and standard library interfaces (filter, reduce, flatMap et al), and ecosystem make propagating information using values extremely ergonomic.
Embracing a functional style in TypeScript is probably the most productive I've felt in any mainstream programming language. It's a shame that the language was defiled with try/catch, classes and other unnecessary cruft so third party libraries are still an annoying boundary you have to worry about, but oh well.
The language is so well-suited for this that you can even model side effects as values, do away with try/catch, if/else and mutation a la Haskell, if you want[1].
If that's something you care about, then don't define your CI build in terms of GitHub Actions steps. Instead, call your build that takes care of using whichever version of Node you want in CI.