3 ms·

> There isn't an "official" NPM package or ES6 model yet (The sqlite team's JS/WASM Guy here...) An ES6 module build was added shortly after the 3.40 release.

by sgbeal 4y ago

> There isn't an "official" NPM package or ES6 model yet (The sqlite team's JS/WASM Guy here...) An ES6 module build was added shortly after the 3.40 release. NPM/node.js are nowhere on our radar. Our build is structured such that people who want to plug it in the resulting JS file to whatever their favorite toolchain is are welcomed to do so, but we have neither the ambition nor the bandwidth to support every build/bundling platform out there, especially ones none of us otherwise use. > It's also very much designed for the browser currently, but again I believe they are intending to support server WASM environments too eventually. The JS code is targeted solely at browsers and there are no plans on changing that in the foreseeable future. The WASM build itself, we are working to provide server-side support for. We have a branch which builds under wasi-sdk, but we cannot create a JS binding for that build until/unless we find some substitute for Emscripten's transparent translation of POSIX I/O APIs.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
justsomeuser 4y ago
Being able to `npm install` this for a frontend app would be very useful.
- simonw 4y ago
  I do think it would be worth SQLite having an "official" npm package - even though setting it up in the first place would require quite a bit of effort. The JavaScript world is culturally so dependent on npm now that adoption of SQLite in that world would massively increase given the availability of a good "official" package. And without an official one I imagine there will quickly emerge dozens of unofficial ones, many of which will end up poorly maintained in the future.
  - tracker1 4y ago
    Especially with the number of "unofficial" packages doing this in a less than standard way.
  - justsomeuser 4y ago
    I agree. It seems strange that they would make an official version and then not add it to the official JS package manager. It seems like Chrome is paying them for the “deliverable” of a JS version, but the spec did not include “npm installable”.
    - sgbeal 4y ago
      > It seems strange that they would make an official version and then not add it to the official JS package manager. None of us in the sqlite use npm in any way, shape, or form, so there's nothing at all unusual about us not publishing anything there. > It seems like Chrome is paying them for the “deliverable” of a JS version, but the spec did not include “npm installable”. Like all deliverables released via the sqlite project, this one was conceived and created as a deliverable which can be distributed through the existing project-level infrastructure. What other people do with it, through whatever infrastructure they like, is entirely up to them. Getting involved with such tooling is way out of scope for us.
  - sgbeal 4y ago
    > And without an official one I imagine there will quickly emerge dozens of unofficial ones, many of which will end up poorly maintained in the future. Seeing as none of us in the sqlite project use NPM or node in any capacity whatsoever, nor do we have any interest in doing so, i'll opine that "unofficial" ones would be of much higher quality than any we would put out. To repeat what i just said in another comment on this topic: Trying to support a tool one neither uses nor understands is like trying to wave away darkness with one's hand.
madeofpalk 4y ago
> but we have neither the ambition nor the bandwidth to support every build/bundling platform out there, especially ones none of us otherwise use. For what it's worth (though it seems like the decisions is done), there's no need to support every build/bundling platform - the NPM registry is rather 'tooling agnostic' and publishing there would make it available to a lot more people with a lot less effort.
- sgbeal 4y ago
  > the NPM registry is rather 'tooling agnostic' and publishing there would make it available to a lot more people ... The sqlite project is populated entirely by C coders (my primary language), none of whom have either experience with, nor a need for, NPM, so we're not eager to claim any level of support for it. Trying to support a tool one neither uses nor understands is like trying to wave away darkness with one's hand. > ... with a lot less effort. A lot less effort on their own parts and a lot more on ours ;). Future NPM support has not been outright ruled out, but it is admittedly nowhere even close to currently being on our radar.

by sgbeal 4y ago

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

justsomeuser 4y ago

Being able to `npm install` this for a frontend app would be very useful.

simonw 4y ago
I do think it would be worth SQLite having an "official" npm package - even though setting it up in the first place would require quite a bit of effort. The JavaScript world is culturally so dependent on npm now that adoption of SQLite in that world would massively increase given the availability of a good "official" package. And without an official one I imagine there will quickly emerge dozens of unofficial ones, many of which will end up poorly maintained in the future.
- tracker1 4y ago
  Especially with the number of "unofficial" packages doing this in a less than standard way.
- justsomeuser 4y ago
  I agree. It seems strange that they would make an official version and then not add it to the official JS package manager. It seems like Chrome is paying them for the “deliverable” of a JS version, but the spec did not include “npm installable”.
  - sgbeal 4y ago
    > It seems strange that they would make an official version and then not add it to the official JS package manager. None of us in the sqlite use npm in any way, shape, or form, so there's nothing at all unusual about us not publishing anything there. > It seems like Chrome is paying them for the “deliverable” of a JS version, but the spec did not include “npm installable”. Like all deliverables released via the sqlite project, this one was conceived and created as a deliverable which can be distributed through the existing project-level infrastructure. What other people do with it, through whatever infrastructure they like, is entirely up to them. Getting involved with such tooling is way out of scope for us.
- sgbeal 4y ago
  > And without an official one I imagine there will quickly emerge dozens of unofficial ones, many of which will end up poorly maintained in the future. Seeing as none of us in the sqlite project use NPM or node in any capacity whatsoever, nor do we have any interest in doing so, i'll opine that "unofficial" ones would be of much higher quality than any we would put out. To repeat what i just said in another comment on this topic: Trying to support a tool one neither uses nor understands is like trying to wave away darkness with one's hand.

madeofpalk 4y ago

> but we have neither the ambition nor the bandwidth to support every build/bundling platform out there, especially ones none of us otherwise use. For what it's worth (though it seems like the decisions is done), there's no need to support every build/bundling platform - the NPM registry is rather 'tooling agnostic' and publishing there would make it available to a lot more people with a lot less effort.

sgbeal 4y ago
> the NPM registry is rather 'tooling agnostic' and publishing there would make it available to a lot more people ... The sqlite project is populated entirely by C coders (my primary language), none of whom have either experience with, nor a need for, NPM, so we're not eager to claim any level of support for it. Trying to support a tool one neither uses nor understands is like trying to wave away darkness with one's hand. > ... with a lot less effort. A lot less effort on their own parts and a lot more on ours ;). Future NPM support has not been outright ruled out, but it is admittedly nowhere even close to currently being on our radar.