It's a shame that including unit tests makes the snippet non-trivial to copy quite fast.

Rust has a nice solution for this though: tests can also be embedded in documentation comments:

    /// Adds one to the number given.
    ///
    /// # Examples
    ///
    /// ```
    /// let arg = 5;
    /// let answer = my_crate::add_one(arg);
    ///
    /// assert_eq!(6, answer);
    /// ```
    pub fn add_one(x: i32) -> i32 {
        x + 1
    }

From: https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-...

More languages could adopt that idea, and a good StackOverflow answer would include those tests in the snippet. StackOverflow might even automatically run the tests and add a passing/failing badge!

In python since 1999: https://groups.google.com/forum/#!msg/comp.lang.python/DfzH5... :-)

(Though not in the stdlib til v2.1, April 2001)

What I would really like is for unit tests to become full fledged features of a language. Any object can contain a Test method (which would be static), this method contains all the unit test code for that object. Select "Run tests" from your compiler, it compiles everything and goes through calling any Test methods it found but the main entry point is never called. A release compile doesn't link the Test methods, nor any method marked [Test] (support functions only needed for testing.)

Elixir has doctests since day 1

https://elixir-lang.org/getting-started/mix-otp/docs-tests-a...

> I feel like this would be a good argument in favour for small scoped packages like we sometimes see on npm.

Rather, I think this is an argument that this kind of functionality should be in the standard library; perhaps in the equivalent of `*printf` for each language.

Download and run code written by strangers without understanding what it does — what could possibly go wrong?

https://www.zdnet.com/article/two-malicious-python-libraries...

Ironic that this was published today. :-)

> Download and run code written by strangers without understanding what it does

Like a web browser does?

There's certainly a risk difference with code that runs in a reasonably well thought out sandbox.

That — and I am not a big fan of browsers getting more and more access to the hardware/OS over time.

That means being beholden to native apps on every platform if you want to do anything at a lower level. I'm not sure that's a better solution.

then it's never possible to use any package/module/plugin anywhere. I get the danger but I'd rather have convenience than writing every function from scratch

I mean, is there, when the snippet is the most copy pasted answer on SO?

No absolutely not! I wholeheartedly despise npm, whenever I try to install a small node app to try it out, npm literally creates tens of thousands of directories, that's not okay for any reason! This is a risk worth taking.

In what language is it any different? It tried to help edit the rust docs. It downloaded > 100 packages and thousands of files. I tried to use some command via brew, it downloaded 15+ dependencies each derived from 100s or 1000s of files.

I agree I don't like the risk but is npm more risky?

> In what language is it any different?

C and C++, which haven’t made the decision to bundle a package manager with a programming language (which is dubious IMO because they are almost completely unrelated concerns), and for which you’re normally supposed to get dependencies from your curated, maintained, OS-provided repositories.

NPM creates a node_modules folder and then fills it with the libraries that your app has specified. Then each of those libraries has their own node_modules folder and NPM will install the dependencies of that library and this happens recursively which is absolutely crazy. The directory structure is A-5.0/B2.0, C-3.0/B2.0, D-3.0/B2.0 which leads to B2.0 being duplicated three times even if it has the same version. Almost every package manager uses a completely different strategy. First of all every package gets a globally unique identifier (in NPM package identifiers are relative to the node_modules folder of which there are many). Usually it is the name of the package and if a package manager needs to support multiple versions of a library within the same program it just adds the version itself to the identifier. This means that if you need B2.0 then it would be stored in node_modules/B/2.0/ and libraries A, C and D would use that single version.

The NPM community is well known for their one liner packages with most of the work done in the dependencies. If that one liner has 5 dependencies and your project transitively depends on it 5 times through react or something then you end up creating 5 times as many files than are needed. It's very easy for a trivial application that uses NPM to have a million files in the node_modules folder.