Fluent Assertions VS ua-parser-js

FluentAssertions para Asserts muy flexibles y entendibles

https://www.nuget.org/packages/Newtonsoft.Json/ https://www.nuget.org/packages/AutoMapper/ https://www.nuget.org/packages/Dapper/ https://www.nuget.org/packages/FluentValidation/ https://www.nuget.org/packages/FluentAssertions/ https://www.nuget.org/packages/NUnit/ https://www.nuget.org/packages/xunit/ https://www.nuget.org/packages/YamlDotNet/ https://www.nuget.org/packages/Moq/ That is simply not true. Mature c# projects purposely maintain no downstream dependencies and is they do, it's to a major reputable lib. See for yourself - these are staple third party packages commonly used. Anything dependency starting with System or NETStandard is Microsoft maintained.

FluentAssertions is one of the most popular (over 66 million downloads on Nuget) .NET library that contains a large collection of .NET extension methods that allow .NET developers to write unit tests using a fluent syntax which is very easy to read and write and clearly shows the intent of the unit test. The library has extension methods to test almost everything related to .NET such as Strings, Booleans, Dates, Guids, Collections, Exceptions, and even Nullable Types. You can add this library to your unit test projects via Nuget package manager and start using this library in few minutes.

I love fluency. I myself work on a package for fluent programming. I recommend you using FluentAssertions for tests though. Nonetheless, keep working! Starred your repo.

For example, all tests below this line are written in Honk# + FluentAssertions (the latter is an example of a library which also provides a lot of fluent methods for xUnit to perform assertions). Soon I'll be moving more of its (AngouriMath's) code to this style, as long as it doesn't harm readability and performance.

fluentassertions / fluentassertions

Just look at all the big companies doing it

https://faisalman.github.io/ua-parser-js/

This project is backed under MIT License, special shout out to project UA-Parser, as liguard uses a piece of its source-code.

With NPM, what's actually published is not what's in the git repo, so it's harder to inspect/review vulnerabilities or hijacking. With composer, what's in git _is_ what composer pulls (with the exception of rules in .gitattributes to exclude files etc), making it much easier to trace. One such example: https://github.com/faisalman/ua-parser-js/issues/536

Composer packages are vendor namespaced, so hijacking an abandoned package is not possible (and it is with NPM), some examples like https://www.theregister.com/2021/08/10/github_npm_package/

Sure, I suppose in theory it could happen with other ecosystems, but for some reason it doesn't. It sure seems to just keep happening in NPM though.

From the other side, npm package may be hijacked(as it happened recently for ua-parser-js and to other packages earlier). To mitigate that, I don't know, probably, subscribing to some security digest would be the most helpful.

On Oct. 22, 2021, developers of a very common NPM package, ua-parser-js, discovered that some attackers uploaded a compromised version of the package containing malware for Linux and Windows, and were capable of stealing data (at least passwords and cookies from the browser).

Since Neovim 0.5 release (which has full Lua support) I see more and more amazing Lua plugins being developed, and I think this trend will likely to continue. But I recently got more concerned about security risks associated with the way Neovim plugins being installed and used (especially after seeing recent compromises like ua-parser-js or coa). Installing typical Neovim plugin is basically downloading and executing random code from the internet on your machine with your user privileges, so hijacked or deliberately malicious plugin could potentially do a lot of damage (like stealing keys/passwords, installing keylogger or just rm -rf / for fun).

thread about compromise https://github.com/faisalman/ua-parser-js/issues/536