Tema: dependencies
-
Sintaxe de intervalos de versão em npm, Cargo, pip, Composer, módulos Go, Maven, NuGet e Bundler
Os operadores caret e til não significam o mesmo em todos os ecossistemas, os módulos Go não têm intervalos, e um número de versão isolado é um mínimo inclusivo no NuGet, mas apenas uma sugestão flexível no Maven.
-
Gerenciamento de extensões do PostgreSQL: instalar, versionar, atualizar e exportar
Uma extensão agrupa objetos SQL e, muitas vezes, uma biblioteca compartilhada sob um único nome, com um arquivo de controle e scripts versionados. CREATE EXTENSION a instala por banco de dados, ALTER EXTENSION UPDATE aplica os scripts de atualização do autor e o pg_dump emite apenas a linha CREATE EXTENSION. Mantenha alinhados os arquivos instalados, a versão no catálogo e a biblioteca carregada, sobretudo em atualizações de pacote e no pg_upgrade.
-
PUBLIC, PRIVATE e INTERFACE no CMake: corrigir o escopo de dependências sem flags globais
Escolha o escopo da dependência a partir do contrato do target consumidor e verifique-o com um consumidor externo mínimo.
-
Dependency confusion: quando um pacote público se sobrepõe a um privado
Se uma build resolve nomes de pacotes entre um índice privado e um público, um atacante pode publicar o nome privado no índice público com uma versão mais alta e conseguir que o seu código seja instalado; a documentação do pip considera inseguro usar --extra-index-url para pacotes privados exatamente por isso. As defesas são namespaces associados a um único registro, um índice único com proxy, fixação por hash e reserva de nomes.
-
Cargo, crates e editions: como um projeto Rust é compilado e versionado
O Cargo compila um crate a partir do Cargo.toml, resolve dependências com intervalos compatíveis com SemVer e grava o resultado no Cargo.lock, podendo incluir duas versões major incompatíveis de um mesmo crate em um único build. As editions são versões da linguagem definidas por crate, de adesão opcional e interoperáveis, de modo que atualizar a edition de um crate nunca obriga seus dependentes a fazer o mesmo.
-
Maven versus Gradle: o que um iniciante precisa saber para compilar o projeto JVM de outra pessoa
O Maven descreve o projeto de forma declarativa no pom.xml e executa fases fixas do ciclo de vida (validate, compile, test, package, verify, install, deploy), às quais se associam goals de plugins; o Gradle executa um grafo de tarefas configurado por scripts build.gradle(.kts) e plugins. Ambos resolvem dependências transitivas, mas com regras de conflito diferentes (Maven: definição mais próxima; Gradle: versão mais alta), e ambos fornecem um script wrapper que fixa a versão da ferramenta de build.
-
Higiene de dependências e verificações da cadeia de suprimentos de software
Saiba do que você depende, fixe e verifique as versões, acompanhe vulnerabilidades conhecidas e compile a partir de fontes confiáveis; os níveis SLSA, o OpenSSF Scorecard e as instalações com verificação de hash oferecem passos concretos.
-
Nomes de pacotes alucinados ou parecidos: verificar uma dependência antes de o agente instalá-la
Modelos que geram código às vezes citam pacotes que não existem; um atacante pode registrar esse nome, e typosquatters registram variações próximas de pacotes populares. Antes de instalar, o agente deve confirmar que o pacote existe, que é o projeto pretendido e que não foi registrado recentemente com um nome confundível.
-
Ordem de dependências com travessia de grafos: BFS, DFS e ordenação topológica
Modele dependências como um grafo dirigido, use busca em largura ou em profundidade para encontrar tudo o que uma mudança afeta e aplique o algoritmo de Kahn ou a pós-ordem do DFS para obter uma ordem de build ou de migração que reporta ciclos em vez de escondê-los; graphlib e tsort implementam a ordenação.
-
Verificar a identidade de um pacote sugerido antes de adicioná-lo a um projeto
Confirme que o nome de um pacote sugerido durante a programação corresponde à dependência mantida que se pretendia, antes de alterar os arquivos de dependências do projeto ou executar hooks de instalação.
-
Software Bill of Materials (SBOM) com SPDX e CycloneDX
Um SBOM é um inventário legível por máquina dos componentes de um artefato de software; SPDX e CycloneDX são os dois formatos mais usados, e gerar um SBOM a cada release ajuda a cruzar vulnerabilidades e a revisar licenças.
-
Cadência de atualização de dependências: lotes, agrupamento e o que integrar de uma só vez
Os bots de atualização abrem um pull request por dependência, salvo configuração em contrário; uma cadência sustentável faz merge das correções de segurança assim que chegam, agrupa atualizações patch e minor em lotes agendados e trata versões major como trabalho planejado. Dependabot e Renovate documentam agendamento e agrupamento, e o guia do Renovate aponta o custo do agrupamento: um grupo que falha bloqueia todos os seus membros.
-
"ERESOLVE unable to resolve dependency tree" do npm e conflitos de peer dependencies
Desde o npm 7, as peerDependencies são instaladas automaticamente, e uma versão que não consegue satisfazer todos os intervalos de peer ao mesmo tempo falha com 'npm error code ERESOLVE' ('npm ERR! code ERESOLVE' antes do npm 10.6). O artigo mostra como ler as linhas Found/Could not resolve do próprio npm para identificar exatamente os pacotes em conflito e por que --legacy-peer-deps ou --force não devem ser a resposta padrão.
-
Listas de materiais de software (SBOM): o inventário da sua própria cadeia de suprimentos
Uma lista de materiais de software enumera, em formato legível por máquina, quais componentes e em quais versões estão num artefato entregue. SPDX (ISO/IEC 5962:2021) e CycloneDX (OWASP) são os formatos mais difundidos; a lista é gerada a cada release a partir do artefato compilado, guardada junto dele e usada para cruzar com avisos de vulnerabilidades e obrigações de licença. Com comprovantes de procedência (SLSA), torna a cadeia de suprimentos verificável.
-
Quais verificações em pull requests de atualização automática de dependências já detectaram uma versão maliciosa ou defeituosa, e quais só geram ruído?
Pergunta em aberto: pull requests de atualização automática chegam todos os dias e muitas vezes são mesclados quando o CI fica verde; a documentação do npm descreve atestados de proveniência verificáveis com npm audit signatures, mas quais verificações (proveniência, revisão do diff do pacote descompactado, inspeção de scripts de instalação, períodos de espera, diffs do lockfile) têm histórico de detectar uma versão comprometida ou defeituosa?
-
Fixar dependências NuGet: PackageReference, gerenciamento central de pacotes e packages.lock.json
O NuGet resolve, no momento do restore, a menor versão aplicável de cada pacote, o que pode causar deriva quando surgem novas versões ou intervalos flutuantes; um build repetível declara as versões uma única vez em Directory.Packages.props, ativa RestorePackagesWithLockFile para que o packages.lock.json registre o fecho completo, versiona o arquivo de lock nas aplicações e restaura com --locked-mode no CI.
-
Empacotando um projeto Python com pyproject.toml
O pyproject.toml declara sistema de build, metadados e dependências em um único arquivo padrão (PEP 517/518/621); com ele, qualquer ferramenta compatível pode fazer o build, instalar e travar as versões do projeto sem setup.py.
-
Ambientes virtuais: um estado de interpretador por projeto
Um ambiente virtual é um site-packages privado associado a um interpretador; criar um por projeto evita conflitos de versão e torna o conjunto de dependências reproduzível e descartável.
-
Builds reproduzíveis e dependências fixadas
Um build é reproduzível quando o mesmo código-fonte e o mesmo ambiente de build geram uma saída idêntica bit a bit; lockfiles com hashes, imagens base fixadas e timestamps fixos são os passos práticos para chegar lá.
-
Go modules: go.mod, go.sum e o sufixo de versão major
Um módulo Go é uma árvore versionada de pacotes descrita pelo go.mod; o comando go escolhe as versões das dependências por seleção de versão mínima, verifica os downloads contra o go.sum e exige um sufixo no estilo /v2 no caminho do módulo para toda versão major acima de 1, de modo que versões incompatíveis tenham caminhos de importação diferentes.
Legível por máquina: JSON