This document is still work in progress.

Please check the mailing list archives for the latest discussions about it.

Introduction

This page describes the policy that packages with Javascript libraries should follow.

Policy

See also Transition Policy

  1. given a foo library, binary package must be called libjs-foo and the source package name should be called foo.js;

  2. should recommend javascript-common in debian/control

  3. should be installed to /usr/share/javascript/foo/

  4. should ship a minified version for each script, generated at build time (use UglifyJS or terser for this purpose)

  5. should generate a node-foo binary package if the script is usable also for Nodejs.

  6. as per Debian Policy ยง 3.5, node-foo packages should not issue a nodejs dependency, just because the library can be used with nodejs. Other reasons can result in such a dependency though.

Please remember that it's preferable if you name the repository after the source package name (i.e. foo.js.git for foo.js). This isn't a hard requirement though.

Proposal

Today most of JS packages does not follow the naming policy. I suggest this:

  1. Naming policy. Given a foo library

    • a browser-only package must be called libjs-foo

    • a node-only package must be called node-foo

    • for a both browser/node binary, browser binary package must be called libjs-foo, node binary package must be called node-foo and the source package name should be called foo.js;

Exclude auto-generated files from source

Strict application of DFSG requires files generated from source in upstream tarball to be excluded, unless it is possible to regenerate the files and prove they are identical to the ones in the tarball.

Minified files and browserified files are examples of such files that could be excluded for that reason. A convenient way to achieve this is to use the Files-Excluded field in debian/copyright, for more information please see repacking and uscan enhancements.

CategoryPackaging