Binary packages should ship a minified version of each script, generated at build time. UglifyJS (package node-uglify) may be used for this purpose.
API changes and parallel installation
Libraries sometimes change their API in incompatible ways, and software might depend on different API versions of the same library. Thus in order to allow multiple versions of the same library to be installed in parallel, different versions implementing different APIs should have different package names and install the library files in different places.
Normally, this should be done by placing a library named foo in a binary package called libjs-fooAPIVERSION (or libjs-foo-APIVERSION where libjs-fooAPIVERSION would be confusing, such as when foo ends with a digit), where APIVERSION is the API version for the library. As an example, if the library's version numbering follows the Semantic Versioning Specification (?SemVer), then APIVERSION would be the library's major version number if the major version number is non-zero. The APIVERSION for a library that does not follow ?SemVer may be different.
The package name should change by updating the APIVERSION when a newer version of the library makes incompatible API changes. API changes that do not result in incompatibility with software written for a prior version do not require a change in the package name.
The source package name may also include the APIVERSION in its name.
If the library is also usable with Node.js, then the source package should also generate a node-fooAPIVERSION binary package. See the Node.js modules policy for more detail.
Source Code Repository
It is preferable if you name the repository after the source package name (e.g. foo.js.git for foo.js), but this is not a hard requirement.