better-sqlite3 icon indicating copy to clipboard operation
better-sqlite3 copied to clipboard

Clean up the npm package?

Open Pomax opened this issue 3 years ago • 1 comments

Installing better-sqlite3 comes with a whopping 9MB deps/sqlite, which should really be cleaned up as either a post-install step, or ideally not even be there unless node-gyp doesn't see a binary it can grab for the OS/Node combination that npm install is running on (although that might not be possible).

(and 9MB might not seem like much, but it's an incredible footprint for small codebases that are themselves less than an MB in code and other deps =)

Pomax avatar Sep 04 '22 17:09 Pomax

which should really be cleaned up as either a post-install step

I think this would break some use-cases that would then require a re-install every time you need to re-compile (e.g. because you switched Node or Electron versions). It also doesn't solve the actual problem: downloading the 9MB for no reason. Not shipping the 9MB as part of your distribution is your problem (e.g. for electron-builder my files config contains "!node_modules/better-sqlite3/{src,deps,benchmark}/**")

If the source is downloaded only when required, the question is from where is it downloaded? How reliable is that (you now need a second service to be online in addition to npm)? How is the integrity verified? Does that mean you need an internet connection if you need to re-compile better-sqlite3?

Maybe you can point to some projects that did something similar and how they solved all these open questions. I'm sure there are some we can look at. But I'm also not the one who makes these decisions.

Prinzhorn avatar Sep 04 '22 18:09 Prinzhorn

e.g. for electron-builder my files config contains "!node_modules/better-sqlite3/{src,deps,benchmark}/**"

:point_up: this is the correct answer.

mceachen avatar Oct 27 '22 22:10 mceachen

Not really, the repo should definitely have all the C++ source code and deps and benchmarks, but a release shouldn't. None of those files are actually related to running the lib as a dependency in a larger codebase. In this case needing to both "satisfy node-gyp" and "be a dependency" are at odds.

So the above solution is the workaround for now =(

Pomax avatar Oct 28 '22 16:10 Pomax

but a release shouldn't

I could be convinced that the benchmark code should be omitted, but the actual source must be present for node-gyp to compile on platforms and targets that aren't prebuilt (like, for example, Node v19 or beta versions of Electron)

mceachen avatar Feb 07 '23 01:02 mceachen

while understandable, I really detest this aspect of node-gyp. there really should be a field in package.json that lets node-gyp tell npm to download "the to-compile-from-source part of the package most people will never need".

Pomax avatar Feb 07 '23 16:02 Pomax