I do get the argument about having an entire module configured/modified/annotated using directives. However, I do think that configuring each export is still superior and more explicit. Again, you might want to configure them differently, which means you don't have to split them in different files.

Not all frameworks use magic functions. Now, does that change your standpoint or do you still argue that a random string is better than an explicit function call, which would provide a lot more flexibility and actually less magic?

Let me know if you need further testing. Happy to help! :)

Since I've never been on that website before: Very, very beautiful website! I really do love the attention to detail in those animations with all of the unique ideas.

Outstanding work! Really looking forward to the cursor size feature :) Great idea and obviously great for accessibility!

Reloading the website in between changing the cursor size didn't work either. It looked the same all the way.

Initially, I also thought the cursor looked a lot bigger when visiting the page with the default cursor size, but that may be intentional.

I've quickly tested it using the latest version of Windows 11 using Microsoft Edge 141.0.3537.99:

In both cases, the default cursor size (smallest) and largest, the cursor on the website *did not* scale up or down.

Meeeeeeeeeeega! Von solchen News wollen wir mehr hören 😍

FYI: In your "Select In Form" case, as soon as you select an option, the formatted item label will display "UNKNOWN" instead of the option's label. However, submitting the form will indeed render the correctly selected option!

All the other cases do seem to work just fine :)

The big underlying question is always: *Should* my change be fully reflected to the outside („public”), or is my change supposed to be „internal only”?

That may or may not be related to me growing up learning C# before slowly dipping PHP, which just got types with v5, and then JS, followed by TS.

If one of those functions will cause an error because I've changed some internal data structure, then it's up to me to figure out how to handle it in *this* particular case, giving me more control.
To me, this is more valuable and more useful in larger code bases.

Depending on your TypeScript configuration, and obviously on your code base, a change in your data structure might cause an error elsewhere, where it's not supposed to error.

I like having explicit return types so that I can control how much will actually flow out to external code.

I know there are tons of arguments about that it's more convenient to have the return type being implicit. I'd argue the opposite. Think about twice when you make a change somewhere and it changes the return type of something that you're not really thinking about at the moment. This will catch bugs.

Yes, to avoid accidental changes to the return type. This is especially important for library code.

It is also super useful when trying to help the compiler for figuring out module boundaries without having to analyze anything but the return type.

Alarmstufe Eis, wir haben einen Notstand. Alle Frauen und Männer an die Eistheken. Erbitte um sofortiges flächendeckendes Spaghetti-Eis-Feuer auf der linken Flanke, wir drohen dort einzubrechen!

Why does Florida now look like a bull‘s testicles?

Europe is not a country. It's not that hard.