Repository navigation
feature-request - include sqlite3 as builtin module for node v9.x #15128
Description
Activity
-1 this is best left to userland.
Reacted by Haroen Viaenebut you have to admit, there are many times when writing "throwaway" scripts on remote/unfamiliar machines, you wished there was a builtin and portable way to persist data other than read/write json files ;)
I'm -1 on this too.
FWIW, one solution is to create your custom version of Node.js by packging sqlite3 as a builtin module, so it does not have to be done in this repo. I am not sure if there is an existing guide on how to do this, but #10187 can be a reference on how to integrate a npm module into Node core.
EDIT: should've link to the PR instead of the commit..
that's a worse solution than npm-installing. there are common use-cases where you would want to write a quick-and-dirty script to transpose/sort/serve a 100mb spreadsheet-like data, with a bare vm and vanilla nodejs, and not bother with the flakiness of npm-install. a builtin sqlite3 would make these expendable scripts simpler and more practical.
e.g. perhaps a 200-line portable standalone script to transform/save datapoints, and then export it in highcharts-format for visualization with various transpose/sort/filter parameters.
@kaizhu256 That's true. But, y'know, the same can be said about numerous packages on https://www.npmjs.com/browse/depended
@joyeecheung , just going thru the list you presented and why are less useful than sqlite3 for quick-scripting:
- lodash - redundant and superseeded by es5
- request - redundant - just use child_process.execFileSync('curl', ...) for throw-away script
- async - overkill for throw-away script
- chalk - just use raw ansi-escape codes in throw-away script
- express - i can write an express-middleware handler in 20 lines of code - https://kaizhu256.github.io/node-utility2/build..master..travis-ci.org/apidoc.html#apidoc.element.utility2.serverLocalRequestHandler
- bluebird - superseded by es6
- commander - just use switch/case statements for process.argv in throw-away script
- debug - overkill for a simple throw-away script
- underscore - redundant and superseded by es5
- react - no common use-case in throw-away scripting
- moment - use native Date objects in throw-away scripting
- mkdirp - redundant - just use child_process.spawnSync('mkdir', ['-p', '/foo/bar/baz'], { stdio: ['ignore', 1, 2] })
- react-dom - no common use-case in throw-away scripting
- colors - just use raw ansi-escape codes in throw-away script
- uuid - i can write the equivalent in 25 loc - https://kaizhu256.github.io/node-utility2/build..master..travis-ci.org/apidoc.html#apidoc.element.utility2.uuid4Create
...
pretty much everything in that list either has no use-case in throw-away scripting or is redundant to builtins in some way. sqlite3, however is not.
Another -1 on this.
You can install sqlite3 in a single shell command.
Node.js has a philosophy of doings its best to enable a good package ecosystem but not pick sides.
Adding something like sqlite3 in Node.js core would have to show a distinct advantage over doing so in userland.
but you have to admit, there are many times when writing "throwaway" scripts on remote/unfamiliar machines, you wished there was a builtin and portable way to persist data other than read/write json files ;)
I agree, and
npm installing it is an excellent way to make sure Node.js supports both sqlite3 and every other database a driver is written for.@kaizhu256 Not every throw-away script is the same. For some throw-away scripts, writing and reading JSON files are pretty enough for persistent storage (in fact "throw-away" seems a bit at odds with "persistent", I would say a lot of scripts only need in-memory storage), for others they are not. This can be said about "using Date v.s. moment" (like for people who does not/does need locales for datetimes), .etc, as you have described, and npm is a good solution to this problem.
I'm also -1 on this. Given the feedback so far, and the fact that we are extremely unlikely to add this feature, I'm going to close this out.
i'm generally happy with nodejs keeping the codebase lean and free of cruft, but sqlite3 is the one exception. it would allow us to write standalone, PERSISTENT webservers in embedded systems with zero-dependencies. recent activity indicates code for the sqlite3 npm-package has stabilized: