bluemonday VS npmgraph

I'm on the receiving end of donations from sourcegraph for this. It's around $10 per month from that single donation and is for the only Go HTML santizer, which you use when you have user generated / untrusted input that you need to display as HTML. https://github.com/microcosm-cc/bluemonday

For me the library has been good enough for my own use for a very very long time. I mostly neglect it unless there's some critical issue. I don't improve it at all as my time is better spent on my day job.

I've often thought that there's room for improvement such as a DOM style santizer to validate input rather than just a SAX style sanitizer, perhaps formatting of output in addition to sanitising input, transformation rules, etc.

When I got the donation I was surprised, first ever bit of support for open source software I'd written (as this was not written on company dime).

Even at $10 per month it's motivating enough to think someone values it. If it accrues into something significant I may actually feel motivated to improve it.

Interesting is that I'd regard this as successful by usage, it's used by virtually everything in the Go world that makes a website.

Perhaps people don't know it exists though? And for that awareness thanks to thanks.dev

bluemonday is an html sanitizer you could try

For sanitizing html input at work we use https://github.com/microcosm-cc/bluemonday.

Sounds like a task for bluemonday.

My thoughts as a maintainer of a HTML sanitizer https://github.com/microcosm-cc/bluemonday

1. Sanitizing is not difficult, defining the policy/config is difficult as your need is not someone else's. First glance of this proposal is that this needs a lot more work to cover people's needs. It's good enough, but will have a lot of edges and will need to evolve.

2. If you allow a blocklist then people will use that by default as it's easier to say "I don't want " than it is to say "I only accept 3. Even if you sanitize something you should keep the raw input... you should store the raw input alongside the sanitized (in fact the sanitized is merely a cached version of the raw input having been sanitized). The reason for this is you will have issues you need to debug (and can't without the input) and you will have round-trip edits you should support (but it's not round-trippable when everything you return is different from the input, do not punish a user who pasted HTML thinking it was safe by then not allowing them to edit it out because you threw everything away). Additionally if you want to ever report on the input, i.e. topK values, and you've modified the input and not kept raw, then you can never do this.

4. Provide a sane default. Most engineers simply do not know what is safe or not. I ship a policy in bluemonday for user generated content... it is safe by default and good enough for most people, and it can be taken and extended due to the way the API is structured so can cover other scenarios as a foundation policy.

I think the proposal in general: specify a standard for a sanitization API has merit. But mostly it has merit if it specifies a standard for defining sanitization policies/configuration, allowing them to be portable across different languages and systems.

The one I wrote is very heavily inspired by https://github.com/owasp/java-html-sanitizer which is the OWASP project one maintained by Mike Samuel. When I did my research before writing the Go one, this was far and away the best way to construct the policy/config and I already saw that this perspective was more valuable than whether it's a token based parser (GIGO but low memory) or a DOM builder (more memory)... no-one cares about the internals, they care about expressing what safe means to them.

This looks a lot better than I expected.

One thing that bugs me about this (and Tailwind) is the number of dependencies they pull in. Panda has 152 nodes (239, if you count their dev-dependencies)[0].

Tailwind has 98 (594 if you count their dev-dependencies).

I know they're only dev-dependencies, but still... I've got all of that code running on my machine, just to process CSS. I really don't love it.

[0] https://npmgraph.js.org/?q=%40pandacss%2Fdev

This is what I came up with. I get 514. I got 496 here https://npmgraph.js.org/. I'm curious what you get using npm and/or yarn, or other tool.

For a real-world example, check out my npmgraph.js.org tool. It crawls a module's dependency tree on the fly, fetching the NPM registry info for each module. For a large dependency graph like the one for gatsby, on my 60 mbps connection the client completes 1,200+ requests (120MB of data) in about 10 seconds.

Why Array.isArray() when you can require("is-array").isArray()?

deep-equal has 43 packages that are mostly has-*, is-* packages (https://npmgraph.js.org/?q=deep-equal) and you’ll find this package included in a lot of upstream libraries.

The great irony of this post is that the author dreams of a world where they can use a library without it depending on hundreds of other modules, yet their website is built on Gatsby, an NPM package with one of the most insane dependency graphs I've seen. Uploading the author's website's package.json[1] into npmgraph[2] lists a total of 1561 dependencies. All that for what amounts to a simple blog site.

[1] https://github.com/poeti8/pouria.dev/blob/master/package.jso...

[2] https://npmgraph.js.org/

You can actually graph the horrible depencency tree of any package you want here: https://npmgraph.js.org/

> Postgres.js is also a zero dependency module, whereas Slonik has quite the dependency graph meaning - compare https://npmgraph.js.org/?q=slonik with https://npmgraph.js.org/?q=postgres.

This one just made my day. Thanks. I remember trying to build a tool at work with as little as possible dependencies (in python) and how satisfying it was to see quite a few dependencies just being wrappers replaces with 5 lines of my own code that i could easily audit and ensure no supply chain attack was possible for that functionality.

Dependency graph. The more dependencies a framework has, the larger the attack surface area. It can also make debugging issues in your applications much more difficult. You don’t need to find a framework with zero dependencies, but you should have some awareness of a framework’s dependency graph. The tool npmgraph can provide you with an excellent overview.

Recognize when you're the person holding the project back: This has happened to me a couple times now. When your interest in a project wanes, be deliberate about recognizing that. Focus what little energy you do have on recruiting people to help out (or even take over).