Hacker News Reader

Comment by TekMol | Hacker News Reader

Independent of the language, I only use external code if it is small enough that I can manually review it. Often I refactor it into a single file during this process.

This of course excludes the majority of packages out there. But apart from security, it has another benefit: These dependency very rarely break and need updates. So compared to projects with a more complex stack, projects with a lean stack are easier to maintain.

It would be great if there was a "single small file packages" movement so that more lean open source software will be created.

View on HN

Does that mean you roll your own database because you can't review the whole codebase for Postgres or whatever? How about your own cryptography suite, and web server, and compiler?

I think it's reasonable to err on the side of rolling your own for simple stuff instead of `npm install is-even` or whatever. But using other people's software is a net positive for both productivity and security for sufficiently complex applications. And the range from "simple" to "complex" is a continuum and it's not trivial to decide where on that continuum to draw the line.

Refactoring into a single file sounds like a bit of a pain, since you have to do it every time the external code gets updated. Also how do you deal with dependencies that come with their own dependencies? Do you avoid them?

    every time the external code gets updated

I do not keep my fork in sync afterwards.

    dependencies that come with
    their own dependencies

Depends on the dependencies. If you give me an example, I can tell you what I would do.

This is a fantastic trick! By copying the source code (which is legal) but not declaring the dependencies in a package.json or similar, nobody will ever get on your case for CVEs in dependencies, and you can save so much time and churn by not updating them.

not necessarily. Depends why the external code was updated and if you need the new functionality.

I'm assuming it isn't a security flaw, because ideally you would have fixed that already during your refactor.

This may be slightly tangential but I recently discovered ncc[1] from vercel which can take a single node project and compile it and all dependencies to a single file.

As an added benefit it also collapses all contained dependencies license files into a single licenses.txt file too!

- [1] https://github.com/vercel/ncc

> It would be great if there was a "single small file packages" movement so that more lean open source software will be created.

There are certainly npm authors doing this already, feross[1] is a good example. That means you get packages like is-buffer[2].

[1]: https://www.npmjs.com/~feross [2]: https://github.com/feross/is-buffer/blob/master/index.js

What I would do if I wanted to use "is-buffer" is I would copy this index.js to a new file called "isBuffer.js" and it would look like this:

    export function isBuffer (obj) {
        return obj != null && obj.constructor != null &&
        typeof obj.constructor.isBuffer === 'function' &&
        obj.constructor.isBuffer(obj)
    }

Imho, there is no need to pull 10 files into my project to use one function.

You would, of course, preserve the copyright and license notices too. Otherwise that would be a violation of the license.

Yes, in this case I would put something like this on top of the file:

    # Fork by TekMol of https://github.com/feross/is-buffer
    # Which is MIT licensed by Feross Aboukhadijeh

I am actually never completely sure how to properly do this. Would the next forker write the following then?

    # Fork by Joe of https://github.com/tekmol/isBuffer
    # Which is a fork by TekMol of https://github.com/feross/is-buffer
    # Which is MIT licensed by Feross Aboukhadijeh

Looking at that function, I'm not convinced that it's copyrightable in the first place. Once you know what it's supposed to do, how else would you express it?

Of course it's only appropriate to credit the author anyway, and one way to do that nicely is by following the license requirements. I just think "violation of the license" is a bit of an unnecessarily strong statement, given the triviality and the likely non-copyrightability of the code.

Your lawyer's opinion may vary.

I think a developer who does that is doing a disservice to the company they are working for. If I start looking at a project and see a bunch of outdated packages that have been copied and pasted there and tweaked who knows how, I quit right away. Not to mention that these packages most likely have various unpatched security issues.

And if the package is not "small enough", I guess it means it needs to be re-implemented from scratch? If a company is happy to pay you for that (and is aware of it), why not, it's fun actually, but not very productive.

>It would be great if there was a "single small file packages" movement so that more lean open source software will be created.

uh, no. what would be even better if TC39 did something beyond window dressing and JS gets a sane standard API so these idiotic requirements for API fill in are no longer required.

These packages are required solely because JS has a crappy API and a vacuum was filled. This increases the surface for supply chain attacks, a la ua-parser-js in Oct.

Other languages have their own issues. But they also have saner stdlibs so the attack vectors are different.

User agent string parsing (already of dubious merit on its own) by no means belongs in the ECMAScript standard. It would fit right in with the work that the Web platform standards bodies are doing, though. If anything, ECMA-262 itself has already gotten too complicated and needs to be pared down to a smaller, look-we-haven't-completely-lost-our-minds profile. Compare ES5 to anything that came after ES2015.

Even ecosystems that do have developer kits with massive API surface area like you want (such as the ecosystem associated with the other TC39 initiative) had the good sense to define collections of common classes separately, speccing out their implementation as being optional. Then again, there's nothing stopping anyone from doing exactly that and just maintaining it outside the scope of the technical committee, a la Boost or Qt in the world of C++. The fact that people try doing this and fail to retain long-term interest from their short attention span colleagues gives you all the evidence you need for why the irreversible step of transmuting that work into a part of JS's core is a bad idea.

> uh, no. what would be even better if TC39 did something beyond window dressing and JS gets a sane standard API so these idiotic requirements for API fill in are no longer required.

That would remove the most used libraries. You could make babel, express, lodash/underscore, moment and stuff like that core, sure. But then you still have people using lots of libraries, especially in the frontend world for components.

> Other languages have their own issues. But they also have saner stdlibs so the attack vectors are different.

There's also more of a culture of just writing things yourself.

Reply on news.ycombinator.com