NoNameProvided

In the risk reduction tab, it should compare the vulnerability count against the node-slim image. In my eyes, it takes away from the offering when they try to prop up the vuln count for the official images, and nobody deploys `node:latest`.

I understand the general point you're making, but the pg package isn’t a good example. It has 6 deps, not 13, and 5 of those are internal packages from the same monorepo without additional dependencies. There’s only a single external dependency, and that one brings in just one additional package.

In my opinion, the pg repo and packages are an example of how OSS stuff should be maintained. Clean repo, clean code, well-maintained readme, and clearly focus on keeping things simple instead of overcomplicating.

Thank you!

Can somebody provide an archive link? Trying to access the site, I get a Cloudflare security page that says my access has been blocked by some security rules.

The target audience also includes Angular developers. NestJS emulates several aspects, such as modules, that it doesn't necessarily need to mimic Angular's appearance.

I cannot pass judgment on whether this is good or bad, but I can easily see how this familiarity can be beneficial for the average programmer.

> For a long time NestJS depended on class-validator ... and regularly suffers from security vulnerabilities that can take years to fix.

As a maintainer of class-validator, I'd like to clarify that this is not accurate. Legitimate security issues, when reported, are promptly addressed. The multi-year security alert listed in NIST NVD is akin to the bogus report that the curl maintainer discussed a few months ago.

In a nutshell, the report suggests that specific settings can potentially lead to validation bypass, which is indeed the case because these settings determine whether unknown objects should fail or pass the validation. This is analogous to my creating a CVE for Windows simply because anyone can access my computer when I haven't set a password.

However, the other part about the scare support is sadly true though.

I think the most bad rep for RxJS comes from using it when it is not needed.

Parent comment said:

> But the problems they solve are also unintuitive.

Do you consider calling a JSON API unintuitive or complex? If not, then you may be using the wrong tool. If you need nothing else, you are perfectly fine using a promise.

If you need to await extra requests, transform them, and react to other events then you need RxJS. For a simple call, you do not.

> I would imagine most people’s use case (mine certainly is) for RxJS boils down to “call a JSON API and receive a response”. That shouldn’t be a hard problem

Do you consider the following code hard to understand or are you are making requests in a more complex way?

``` this.network.get('<url>').subscribe(response => <do whatever you want here>) ```

Even if we agree to disagree that the above code snippet is hard to understand, you can just convert it to a promise:

``` const response = await lastValueFrom(this.network.get('<url>')) ```

> I can just note that our Angular code seems to be much harder to maintain than our React code.

A big part of maintainability comes from the quality of code and/or existing experience with the two frameworks, not the frameworks itself.

I work at an Angular only shop, if we would write some React it would be probably harder to maintain for us than the Angular ones.

Angular did have it, it is called RxJS.

From OP post:

> ...team is great and lot of interesting challenges...

A great team and exciting challenges are a strong retaining factor, and I dare to say, it's way harder to find a job that excites you than one which pays well.

It's worth a note that this was introduced with the latest DLC, and the AI currently is hopelessly broken as it does not understand the importance of defending your railway lines connecting your supply depots.

You can set Actions to required and then they will be displayed even when Actions is down and merge will be prevented.