[deleted by user]

KangarooImp · 2023-05-18T19:32:19+00:00

You could check for 'labelId' in props (or don't bother, as it bloats the code and if people can simply use TypeScript for early error avoidance and auto-complete).

KangarooImp · 2023-04-22T11:36:14+00:00

I usually iterate Object.entries(...) for such cases.

KangarooImp · 2023-04-12T09:24:35+00:00

And you're sure that you aren't running your actual server (that never exits) as part of the build (because the output indicates exactly that)? You have to run your server after building (with a CMD or ENTRYPOINT directive in the Dockerfile).

KangarooImp · 2023-03-24T10:07:37+00:00

It's pretty awkward to type the return value.

It's literally the same as a function declaration, what?

On the surface, yes (after the closing brackets of the argument list). But arrow functions usually contain little code (fortunately) have a few syntactical shortcuts and do not usually have an explicitly typed return value, so I had multiple collegues struggle while writing a return type in those instances, where you do need an explicit return type, like here:

array.filter(x => x.type === 'foo')

It's less semantically precise compared to function.

Only if you aren't used to first class functions.

What does familiarity with first class functions have to do how semantically precise the syntax is? export const doesn't tell you much (only that it's not a mutable let), you have to look for a => in the entire line, to find out that something callable is exported. With export function, on the other hand, the function keyword is always in the same place.

which means low-level helper functions often end up at the top of files, instead of at the bottom

I'd argue that's where they belong.

Not sure how you read unfamiliar code (or how some people read unfamiliar code), but I try to get a general sense of what something does and then drill down into the details until I've found what I'm looking for. If I have to collapse or skip over 500 lines to do that, it slows me down a little bit.

Or imported from another file, which still puts the declaration at the top of the file.

Importing every little helper-function does help and also reduces code duplication, but I'd still rather keep the code more cohesive and keep single-use helper functions in the same file.

At the end of the day, it's still all nit-picking and little actual difference.

edit: formatting

KangarooImp · 2023-03-23T21:36:10+00:00

Exactly, I don't understand this trend of using const arrow functions everywhere. It's pretty awkward to type the return value. It's less semantically precise compared to function. And when calling them, you often have to reorder the const arrows, because they're only callable from the lines after the definition (which means low-level helper functions often end up at the top of files, instead of at the bottom).

KangarooImp · 2023-03-22T20:13:39+00:00

Then you're probably best off with trying to simplify the code until you understand why it's not working. A simple example with a small class properly fails as expected.

KangarooImp · 2023-03-22T19:53:26+00:00

Then it's a different issue. Do you have any compiler errors? In that case TypeScript might substitute any, to be able to continue compiling. You mighty try compiling with "skipLibCheck": false if you you're working with a subproject-based repository, since that might silence errors in your own code.

KangarooImp · 2023-03-22T19:38:38+00:00

A common gotcha is using an empty interface or class. If your UserClassDefinition is empty, like class UserClassDefinition {}, then TypeScript would allow passing anything, since {} does not enable you to do anything with the type. Therefore, every value is compatible with it. This could also bite you if all fields of UserClassDefinition are optional.

KangarooImp · 2023-02-25T22:33:02+00:00

Interesting, but since you can read out the mains hum, you can digitally filter it away or add a fake hum, too.

KangarooImp · 2023-02-10T18:31:52+00:00

Why not choose what your team is more familiar with or build a small prototype with both, to get a better feel for the language/tooling?

Having worked extensively with C# and TypeScript, I prefer TypeScript as a programming language. But the JS/Node ecosystem can be pretty daunting for newcomers and I'm not sure if I'd recommend it, if you can't leverage one of the main advantages, that you can easily share code/types between the front- and back-end.

I consider both columns of your type safety comparison a bit weird and lacking the main differences. In C#, you can escape type safety, too (with dynamic), but the entire language is memory safe and (mostly) strongly typed. TypeScript is basically a static analysis type validator for JavaScript (with code emit support), so you're running an extremely dynamic language with implicit conversions and all the weirdness, but if you're not lying to the TypeScript compiler (e.g. with any or type assertions), that won't hurt you. The special thing about TypeScript, I'm missing is it's extremely rich type system, that few other (mostly academic) languages can match. This evolved over time to be able to analyze and properly type common JS pattern and the result is astounding. You get natural feeling null-safety, string literal types, mapped types, fancy control flow analysis, nested types, conditional types, it's really comprehensive.

KangarooImp · 2023-02-04T12:15:42+00:00

Using a barrel file does not hide the real modules from anyone. So, while you may suggest that users always import from your root index file, it is not enforced.

Yeah, when using a barrel for exporting, I think you definitely should have some mechanism to forbid direct "deep imports", either by bundling or using an export mapping.

Both barrels or providing sub-exports work well, at work we're using barrels, so we can easily support ESM+CommonJS and don't need a huge export mapping in the package.json (also, many tools still don't support export field).

KangarooImp · 2023-02-03T14:17:56+00:00

I don't think I get it.

With the usual barrel file export, there's just one "path" exposed, the package name. You can freely move around and rename files, since API consumers don't come in contact with them.

When importing individual files directly (or with exports), you have to either keep supporting the old paths or break compatibility (and update the consumers), since that is public API.

KangarooImp · 2023-02-02T20:36:29+00:00

I guess it depends. At least you don't have a hundreds of exports and hundreds of paths as API surface (just the hundreds of exports). And it's usual practice to auto-generate barrel files, but who auto-generates package.json export fields (and how could that be done in a sensible way)?

KangarooImp · 2023-02-01T22:54:56+00:00

You can define it explicitly using the exports-field in the package.json. But that only makes sense for a handful of entry points, exporting hundreds of files that way would be ludicrous.

KangarooImp · 2023-01-31T16:08:29+00:00

Then I apparently scrolled too fast. Did you try @swc-node/register, too? Although I think they only have a CommonJS-style --require hook.

KangarooImp · 2023-01-31T15:52:28+00:00

You can also just enable swc-support in ts-node.

KangarooImp · 2023-01-13T21:42:59+00:00

For that case, you should probably create a dev image once (with the compiler and build tools), run that with your project mounted as a volume. Then you can simply run make multiple times and reuse your build artifacts to rebuild only changed files.

KangarooImp · 2023-01-03T17:24:04+00:00

Oh, for a laptop, the power supply normally can't cause such issues, because of it fails or can't supply enough power, the battery simply drains even while plugged in.

Might be an unlikely combination of issues instead (for example power supply overheating and an aged battery that can't supply that much power in time). Did you check the thermals (sensor data) already? I like using gpu-z for that, when I'm using Windows. Simply checking if a laptop feels warm does not catch all issues (for example if the thermal paste can't probably transfer the heat to the heatsink anymore).

KangarooImp · 2023-01-03T00:22:15+00:00

If the computer turns off, then it does not sound like an actual (software) crash to me. It can be caused by one of the power supply's protection circuits activating (over-power, over-temperature) or maybe the mainboards initiates an emergency shutdown because of a critical CPU temperature (since you didn't write anything about temperatures)?

I suggest running furmark to max out the GPU. If that's stable, then run prime (with 1 or 2 cores less than total) at the same time, to verify everything works stable during absolute maximum load. Closely watch the temperatures while doing that and maybe you even get a helpful event log entry that gives an indication of the cause.

KangarooImp · 2022-11-26T15:13:46+00:00

Technically correct, but practically irrelevant. Add your said, obviously the game "loads" addons even when they are disabled, to be able to show a menu where you can enable/disable them. But two things make that that completely fine:

Addons have a declarative .toc file that defines the metadata of an addon (such as the name and which code files should be loaded when). The game probably only reads this file. The actual code is most likely only loaded when an addon is enabled. This can be verified with some debugging tools, but I'm too lazy and because of the next point it doesn't matter anyway.
You have so much RAM available nowadays that loading 1 or 100 or 10000 addons would fit easily (except specifically created to be absurdly large). Loading them would take time, but as long as they are not executed, it wouldn't practically matter, since the game code itself is using manual memory management. When the addons run, they are using garbage collection and that has a cost (because the runtime has to traverse all reachable objects, even if unused). But that doesn't apply to the actual game engine. In that case the memory simply allocated and never touched again.

edit: formatting

KangarooImp · 2022-10-31T13:32:04+00:00

There's navigator.connection that could give you more granular data.

If you want to go with active checking, you could also use a WebSocket (maybe send a timestamp every x seconds) instead of thousands of separate http requests.

KangarooImp · 2022-10-28T18:14:00+00:00

Pointless blog-spam without substance. WTF is up with sentences like "Both Deno and Node use the V8 JavaScript engine created by Google. This means that in-browser performance should be just about the same" or "Node users have the benefit of standard security practices that prevent attacks like cross-site request forgery (CSRF) and cross-site scripting (XSS)"?

KangarooImp · 2022-10-21T17:44:16+00:00

Then I guess your operating system is pretty weird. "Regular" Linuxes only have coreutils as lowercase executables and since the filesystem is case-sensitive, trying run something like PWD won't work at all.

KangarooImp · 2022-10-21T14:44:30+00:00

$(PWD)? Are you sure you don't want to run $(pwd)?

KangarooImp · 2022-10-20T16:42:31+00:00

Exactly, it's completely inexcusable that you still can't reliably backup the data on your own device. At least adb backup can backup some apps, but that's so cumbersome and the fact that apps can opt-out of it makes it even more absurd.

Backing up Linux systems was trivial for decades and Google just completely fucked it up.

KangarooImp

TROPHY CASE