Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

SQLite in core: maintenance trade-offs compared with other language ecosystems

Aberta
  • Algo errado?
#65,974 1 comentário 3 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
55/100
Tipo de issue
Documentação
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
nodejs, sqlite
Domínio
documentation

Direção de pesquisa

Comece lendo as issues #49663 e #53264 e, em seguida, revise a documentação atual de node:sqlite. Adicione uma explicação concisa sobre os trade-offs de manutenção, por que SQLite permanece no core e como os usuários podem determinar se as correções de segurança do SQLite exigem uma atualização do Node.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

question

I've been reading #49663 and #53264 to understand how SQLite ended up in Node core. I understand that it was first accepted for localStorage, and that exposing node:sqlite followed from that.

Looking at other ecosystems, there seem to be a few different approaches:

  • Python includes the sqlite3 wrapper in its standard library, though how the SQLite engine is supplied depends on the distribution.
  • Java provides JDBC, while SQLite support comes through a separate driver.
  • .NET provides an official Microsoft.Data.Sqlite package, installed separately through NuGet.
  • Go provides database/sql and leaves the actual drivers to external packages.
  • Bun and Deno both provide built-in SQLite APIs.

The .NET approach seems particularly interesting here: users get an officially maintained integration, but its updates can be delivered separately from the runtime.

Given that Node already needs SQLite for localStorage, how much additional maintenance and security exposure comes from offering the broader public API? Was an official, separately distributed binding considered, and what made keeping it in core preferable?

I'm also curious how this works in practice when SQLite publishes a security fix. Where can users find out whether it affects Node's build and exposed functionality, and whether a Node update is needed?

A short explanation of these trade-offs in the docs would be useful. The original issues explain the path to inclusion, but I still have trouble understanding the long-term maintenance implications. Happy to be pointed to an existing discussion if I've missed it.

Linguagem predominante
JavaScript
Estrelas
122k
Forks
38.4k
Merge médio
4d 10h
PRs com merge (30d)
276

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de nodejs/node

Todas as issues de nodejs/node

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.