Except you hit limits when trying to share that URL. Eg: try pasting a URL longer than 4096 bytes in Signal or WhatsApp, and they don't render it as clickable.
Thanks for the feedback, Vercel domain uses nuqs [1] (I'm the author) for URL state, and I agree flooding the browser history is a bad experience.
Is there a way to update the URL (ie: keeping it reactive in the address bar) without creating those history entries, or to ask the browser to squash the last entry it created into the previous one?
I am not aware of any approaches that work consistently across all major browsers. This matter is nothing new -- there's a Bugzilla report[0] from 13 years ago about this behavior that remains open.
Since there's no spec for global history and it's unlikely one will be introduced, the most practical solution to avoid flooding the browser history would be to debounce the changes.
This is the approach taken by Google Maps -- with maps being a well-known case where URL updates would clutter the history, as noted in the Bugzilla report.
The reaction (removing the package) is also similar to an inexperienced developer when confronted to their first vulnerability report.
Assuming good intentions (debugging) rather than malice was at play, communication is key: drop the malicious version of the package, publish a fix, and communicate on public channels (blog post, here on HN, social media) about the incident.
A proper timeline (not that AI slop in the OP article) also helps bring back trust.
It has a (albeit experimental) flag for transforming enums, namespaces and other runtime-impacting aspects of TypeScript, if that’s what you were referring to?
My go to for formatting would be clang-format, and for testing gtest. For more extensive formatting (that involves the compiler) clang-tidy goes a long way
Clang tidy does both: it can run clang's analyzer [0] (also available with clang++ --analyze or the scan-build wrapper script which provides nicer HTML-based output for complex problems found), has it's own lightweight code analysis checks but also has checks that are more about formatting and ensuring idiomatic code than it is about typical static analysis.
MVSC [1] and GCC [2] also have built-in static analyzers available via cl /analyze or g++ -fanalyzer these days.
There is also cppcheck [3], include-what-you-use [4] and a whole bunch more.
Running unit tests with the address sanitizer and UB sanitizer enabled go a long way towards addressing most memory safety bugs. The kind of C++ you write then is a far cry from what the haters complain about with bad old VC6 era C++.
It's "great" mainly in the sense of being very large, and making your code very lage - and slow to build. I would not recommend it unless you absolutely must have some particular feature not existing elsewhere.
Anthony Fu’s epoch versioning scheme (to differentiate breaking change majors from "marketing" majors) could yield easy winners here, at least on the raw version number alone (not the number of sequential versions released):
I don't know if this is the origin, but the semver spec says 0.x.y is unstable. Sure, not everybody uses semver, but it is popular enough for people to make incorrect assumptions.
It's not the origin. Using 0.x for stuff like this was already a thing long before semver. For example, the very first release of Linux in 1991 was v0.01.
reply