DFSG NEW review for node-lucide version 1.52.0-1

Summary

• Licensing is DFSG-compliant and debian/copyright is accurate: No
• Packaging is of good quality: No
• Issues: 1 blocker, 5 important, 4 minor
• debian/watch: version 5
• debian/copyright: machine-readable
• Scan before the review: 2 found

Licensing

The upstream licensing itself is DFSG-compliant: the only licence file is the ISC licence with an MIT (Expat) section for the Feather-derived icons, both texts are reproduced in debian/copyright, no non-free wording or licence-restricted assets were found, and every package.json says ISC. However, debian/copyright is not accurate for the whole source: debian/* and the four Debian patches are Andrew Lee's work, yet the only Files stanza attributes everything to Lucide and Cole Bemis. The file is otherwise in DEP-5 format and needs no replacement.

Packaging

The packaging does not build the component it declares as main, its Debian-specific rollup patch removes the ESM output that packages/vue/package.json still advertises, and its hand-written Vue generator passes icon metadata where the library expects SVG node data, so generated components cannot render. There are smaller defects too: a rollup plugin imported under a name the Build-Depends does not provide, no dependency on nodejs, a no-op autopkgtest, build leftovers in the tarball, and an incomplete clean target.

Issues

1. [blocker] [licensing] debian/copyright omits the Debian packaging copyright

• Files: debian/copyright:6-9, debian/control:5, debian/patches/fix-ast-with-babel-ts.patch:13
• Basis: checked, in the package or with a reference tool
• Evidence: Files: * / Copyright: 2026 Lucide Icons and Contributor / 2013-2016 Cole Bemis; there is no Files: debian/* stanza, while the patches say From: Andrew Lee (李健秋) <ajqlee@debian.org> and the changelog is signed by the same person.
• Problem: The Debian packaging (debian/rules, debian/control, the generator, debian/nodejs/, and the four patches) is Andrew Lee's copyright, not upstream's. Attribution of those files to Lucide under the upstream licences is inaccurate, and the debian/ files carry no stated licence at all (Policy 12.5, copyright-format 1.0 §5.2). The upstream holder name is also misspelled: LICENSE says Lucide Icons and Contributors.
• Fix: Add a Files: debian/* stanza naming 2026 Andrew Lee (李健秋) ajqlee@debian.org with the licence chosen for the packaging (ISC is consistent), and correct Contributor to Contributors in the upstream stanza.

2. [important] [packaging] Build script never builds the component that debian/main declares

• Files: debian/main:1, debian/nodejs/build:4-22, packages/lucide/src/icons/.gitkeep, packages/lucide/package.json:18-19
• Basis: inferred from what was read, not seen directly
• Evidence: debian/main contains packages/lucide, but the whole build script is # 1. Build packages/shared first and # 3. Build packages/vue; packages/lucide/src/icons/ contains only .gitkeep, and there is no packages/lucide/dist.
• Problem: dh-nodejs installs the component named by debian/main. That component is never built: its icon sources are generated by build-icons at build time and its rollup bundle is not run, yet its package.json points main at dist/cjs/lucide.js. The binary therefore cannot contain a usable lucide module. Conversely the Vue module that is built is not the declared main component, and the autopkgtest files name packages/vue, so the intent is inconsistent.
• Fix: Build packages/lucide (build-icons plus rollup) as the main component, or set debian/main and the description/test to packages/vue; make the build, main and test agree.

3. [important] [packaging] Declared ESM entry point is never produced

• Files: debian/patches/fix-ast-with-babel-ts.patch:32, debian/nodejs/build:25, packages/vue/package.json:25-26
• Basis: checked, in the package or with a reference tool
• Evidence: The patch adds inputs.filter(() => format !== 'esm'), dropping the only config that emitted .mjs; the build then runs Babel with --out-file-extension .js; packages/vue/package.json still declares "module": "dist/esm/lucide-vue.mjs" and has no "type": "module".
• Problem: Nothing produces dist/esm/lucide-vue.mjs. The Babel ESM tree is dist/esm/*.js in a package without type: module, so Node interprets it as CommonJS and fails on export; bundlers that honour module are pointed at a non-existent file. The ESM distribution is unusable.
• Fix: Keep the ESM rollup output (preserveModules with the .mjs extension) in the rollup config, or emit .mjs from Babel and declare matching exports; do not filter out the ESM bundle while package.json advertises it.

4. [important] [packaging] Vue icon generator passes metadata JSON as SVG node data

• Files: debian/generate-vue-icons.mjs:28-32, icons/a-arrow-down.json:1-11, packages/vue/src/createLucideIcon.ts:25-38
• Basis: checked, in the package or with a reference tool
• Evidence: The generator reads each icons/<name>.json and emits createLucideIcon('${pascalName}', ${JSON.stringify(iconData)}); the JSON contains only $schema, contributors, use-cases, tags, categories and sometimes aliases, with no node member. createLucideIcon stores the second argument as node, and buildLucideIconNode then calls icon.node.map(...).
• Problem: Every generated Vue component receives an object where an array of [tag, attrs] SVG nodes is required. The actual path data is in the sibling .svg files and is never read, so rendering any generated icon throws (icon.node.map is not a function) and no artwork is bundled. This replaces upstream's build-icons, which extracts the nodes from the SVGs.
• Fix: Generate the components with the upstream @lucide/build-icons/exportTemplate pipeline, or parse icons/*.svg into the node array before calling createLucideIcon.

5. [important] [packaging] Patch imports a rollup plugin name the Build-Depends does not provide

• Files: debian/patches/replace-rollup-plugin-esbuild.patch:15, debian/control:13, debian/nodejs/extlinks:15
• Basis: inferred from what was read, not seen directly
• Evidence: The patch adds import typescript from 'rollup-plugin-typescript';, and extlinks also names rollup-plugin-typescript; the Build-Depends has node-rollup-plugin-typescript, whose apt-cache entry is version 12.3.0 and Homepage https://github.com/rollup/plugins, i.e. the @rollup/plugin-typescript module.
• Problem: Debian's node-rollup-plugin-typescript is @rollup/plugin-typescript, not the abandoned rollup-plugin-typescript package the patch imports. Unless that package installs a compatibility path under the old name, rollup -c fails to resolve the import. The options passed (include, top-level module, ignoreDeprecations, and the spread of esbuild options) are also not @rollup/plugin-typescript's interface (it takes compilerOptions).
• Fix: Import @rollup/plugin-typescript and pass include/compilerOptions as that plugin documents, or drop the plugin in favour of the existing Babel/TypeScript setup.

6. [important] [packaging] Binary package has no dependency on nodejs

• Files: debian/control:28-29, debian/control:8
• Basis: inferred from what was read, not seen directly
• Evidence: Depends: contains only ${misc:Depends}, while Build-Depends uses debhelper-compat (= 13). debhelper's own compat notes state that relationship substvars are added automatically only from compat 14; at 13 a substvar must be written in the field.
• Problem: ${nodejs:Depends} is the substvar dh-nodejs fills with nodejs:any; because it is absent, the resulting package depends on no interpreter it needs to run, contrary to Policy 3.5. If packages/vue is the module that ends up installed, the runtime dependency on node-vue is absent as well.
• Fix: Add ${nodejs:Depends} to Depends (and node-vue if the Vue module is shipped), or raise the compat level to 14 so the relationship substvars are applied automatically.

7. [minor] [packaging] Autopkgtest always succeeds because its only command is commented out

• Files: debian/tests/pkg-js/test:4-5, debian/tests/pkg-js/files:1
• Basis: checked, in the package or with a reference tool
• Evidence: The script's whole body is # Test local require from packages/vue directory and #node -e "require('@lucide/vue')".
• Problem: The generated pkg-js test runs a script that does nothing and exits 0, so the package reports a passing autopkgtest that cannot detect even a missing module entry point.
• Fix: Uncomment or replace the check, for example node -e "require('@lucide/vue')" in the directory named by debian/tests/pkg-js/files, after making the installed module actually resolvable.

8. [minor] [packaging] Upstream tarball ships an Angular build cache with developer paths

• Files: packages/angular/.angular/cache/21.2.19/ng-packagr/10874da3fb3e1c9df348ed355bf2b0ca82dbe0c880cf69f052802c177281d5e7, packages/angular/.angular/cache/21.2.19/ng-packagr/tsbuildinfo/lucide-angular.tsbuildinfo
• Basis: checked, in the package or with a reference tool
• Evidence: The cache contains a 112 KB serialized ng-packagr index and an 870 KB tsbuildinfo full of absolute paths such as /Users/eric.fennis/Development/lucide/packages/angular/dist/tmp-typings/....
• Problem: These are machine-generated build products of packages/angular, which is not built or installed by this package. They add noise and leak the upstream developer's home directory, and nothing in the package uses them. They are not needed for modification because the TypeScript sources are present, so this is a source-hygiene issue rather than a DFSG one.
• Fix: Repack the upstream tarball to exclude packages/angular/.angular/ (Files-Excluded or the uscan repack), or have upstream remove it.

9. [minor] [packaging] Clean does not undo the generated Vue sources and the rewritten tsconfig

• Files: debian/clean:1-7, debian/generate-vue-icons.mjs:100
• Basis: checked, in the package or with a reference tool
• Evidence: The generator writes packages/vue/src/icons/*.ts, packages/vue/src/aliases/{aliases,prefixed,suffixed}.ts and overwrites packages/vue/tsconfig.json; debian/clean only lists dist, node_modules, .rpt2_cache and .tsbuildinfo.
• Problem: After a build the source tree is left modified, including a tracked upstream file (packages/vue/tsconfig.json) that clean cannot restore. Policy 4.9 requires clean to undo the effects of build and binary.
• Fix: List the generated packages/vue/src/** files in debian/clean and stop rewriting tsconfig.json during the build (generate a temporary config or carry the change as a patch, restoring the original on clean).

10. [minor] [packaging] Typo in debian/upstream/metadata Repository-Browse

• Files: debian/upstream/metadata:5
• Basis: checked, in the package or with a reference tool
• Evidence: Repository-Browse: hhttps://github.com/lucide-icons/lucide
• Problem: The value is not a URL, so the metadata field is broken for anyone consuming it.
• Fix: Change hhttps to https.

Verified

• Read every file under debian/ in full: control, rules, changelog, copyright, clean, gbp.conf, main, nodejs/{build,extlinks,root_modules,additional_components}, babel.config.json, generate-vue-icons.mjs, all four patches and series, tests/pkg-js/{files,test}, upstream/metadata, salsa-ci.yml.
• Licensing: the only licence file in the tree is the root LICENSE, an ISC licence followed by an MIT (Expat) section for the listed Feather-derived icons; debian/copyright reproduces both texts in full and uses no /usr/share/common-licenses pointer. Every package.json in packages/ and tools/ declares ISC. No SPDX headers, no additional LICENSE/COPYING/NOTICE files anywhere, and no non-commercial, no-derivative or field-of-use wording (grep for those terms returned nothing).
• The scan's questioned holder is a false positive: Lucide Icons and Contributor in debian/copyright is the LICENSE's Lucide Icons and Contributors (singular/plural typo), not a different entity.
• Tree inventory: about 5,600 files; checked icons/ (SVG plus JSON metadata, including the aliases embedded in the JSON), lab/, categories/, docs/ (including docs/public and docs/images), packages/, tools/, scripts/, integrations/ and the repository metadata. No dist/, node_modules/, minified JS/CSS, archives or compiled binaries were found apart from the Angular cache.
• docs/public/templates/illustrator_template.ai: an Adobe Illustrator template (PDF-compatible, 431 KB) referenced by docs/contribute/illustrator-guide.md. It is the editable vector artwork itself, not output generated from missing sources, and is covered by the upstream Files: * ISC grant.
• docs/public/templates/affinity_designer.aftemplate: an Affinity Designer template referenced by docs/contribute/affinity-designer-guide.md. It is the native editable artwork, not a generated build product, and likewise covered by the upstream ISC grant.
• docs/public/og.png, docs/public/og/general.png and the docs/images screenshots are site artwork with their generator sources (docs/.vitepress/createOGImage.ts and the SVGs) present; the .png/.ico/.svg assets carry no separate licence notices.
• Patches all carry DEP-3 Description/From/Forwarded headers and apply in the listed order; series order matches the successive context of tools/rollup-plugins/plugins.js.
• debian/changelog: version 1.52.0-1, distribution unstable, initial release closing #1150297, signed with a current date.
• Standards-Version 4.7.4 matches the current Policy 4.7.4.1 (first two components 4.7), so it is not an issue. Build-Depends names all exist in the archive (checked node-rollup-plugin-typescript, -license, -dts, -node-resolve, -replace, node-preact, node-minimist, node-vue).
• uscan found upstream releases with debian/watch; a newer upstream version is available (upstream 1.59.0, packaged 1.52.0), which is not a fault of the package.

Not confirmed

• I could not build, so the concrete effect of debian/main versus debian/nodejs/build, and whether node-rollup-plugin-typescript installs a rollup-plugin-typescript compatibility path, would be settled by a build log.
• The third-party brand logos under docs/public/company-logos/, docs/public/framework-logos/, docs/public/library-logos/ and docs/public/sponsors/ carry no licence or attribution notice; I could not confirm that Lucide has the right to license these marks under the blanket Files: * ISC grant. They are used only by the documentation site, which is not installed.
• The prescan reports one text file longer than 4 MiB that it scanned only in part; I did not identify which file it is, and no licence or copyright wording was found in the parts of the tree I searched.
• The two template binaries and the PNG/ICO images were not opened; they were judged from their paths, the documentation that references them, and the upstream licence.

Proposed changes

None.