sara-nl/js-webdav-client: a webDAV library whose dist.js is a concatenation

The build downloads a minifier and needs Java

There is no bundler in this project and no node_modules step for producing the distributed file. The Makefile's default target builds dist.js, docs and tests, and the dist.js rule depends on a target called check-minifier-dependencies, which runs a shell script in the scripts directory. If yuicompressor.jar is not already in the working tree, the rule downloads the YUI Compressor 2.4.7 archive from a GitHub downloads URL, extracts only the jar from inside it with unzip piped to stdout, deletes the zip, and then runs the jar under `java` with `--type js`, `--charset utf-8` and `--preserve-semi` to produce dist.js from dist-unminified.js. In practice that means a minified build needs a Java runtime present, and the first build on a fresh clone reaches out to the network before it can produce anything.

dist.js is the sources in name order inside a UMD wrapper

The single-file build is a concatenation, and the Makefile shows exactly how. The source list is two globs, `src/*.js` and `src/plugins/*/*.js`. The rule first removes any previous output, writes `src/UMD-header.txt` as the opening of dist-unminified.js, then appends every matched file in turn followed by a newline, printing an added-to-build line as it goes, and finally appends `src/UMD-footer.txt` to close it. So the distributed artifact is the library's own files, in filename order, wrapped in a universal module definition that lives in two text files rather than in code. Nothing is renamed, nothing is tree-shaken and nothing is deduplicated, which is also why the order of those filenames turns out to be part of the public contract rather than an internal detail.

Load order is the contract when you link sources directly

If you skip the single-file build and link the sources from an HTML page instead, the order is fixed and the README is explicit about it. You add the files you need with plain script tags, starting from the header.

<script type="text/javascript" src="/library_path/src/000_header.js"></script>

Files directly in src are included in sorted order first: 000_header.js is linked first, 001_exception.js next, then 002_iehacks.js, then the rest. Directories under src/plugins come after that, again in sorted order, and the files inside each of those are sorted too. The stated purpose of that arrangement is that the basic library is linked before any plugin loads. One small documentation slip is worth noting while you follow it: the list describes both 001_exception.js and 002_iehacks.js as second, when the filenames themselves make the intended order clear.

Two license files, and two different answers about which one

The repository ships the classic dual pair of license texts, and the README names what each one contains. `COPYING.LESSER.txt` is the GNU LGPL, and `LICENSE.txt` is the GNU GPL, so the intent is a library available under both. The details get fuzzier once you look at the metadata. The repository's own license field states GPL-3.0, while the `license` field inside package.json declares `LGPL-3.0+`. So the two answers name different halves of the same arrangement rather than conflicting outright, but they are not the same statement, and which one you are subject to depends on whether you are reading the repository or the package. The author field is SURFsara, the project is published under the name js-webdav-client, and the version has been 1.0.0 across the whole life of the file.

The typings field is misspelled, so the types may be invisible

The package manifest points at generated artifacts directly. `main` is dist.js, and the type definitions live in a file called dist.d.ts, which is itself committed to the repository alongside dist.js and dist-unminified.js. The field naming them, however, is written as `typeings` rather than `types`. That is not a stylistic choice: the field consumers and bundlers read is `types`, so a toolchain that resolves types by looking for `types` or for a matching declaration file will not be told about dist.d.ts through this manifest. Everything else in the manifest is minimal in the same spirit. There is no dependencies block, no files allowlist and a single script, where `test` simply delegates to `make test`. Directories for docs and tests are declared as `directories` entries rather than in the usual places.

The test suite is two generated HTML pages

Tests are not run by a headless runner. The Makefile gathers them from `tests/unittests/*.js` and `tests/unittests/plugins/*/*.js`, then assembles a temporary footer file containing one script tag per test file. From the templates directory it copies tests_header.html into tests/run_dev_tests.html and appends every source file, producing a page that loads the library straight from src. It then copies the same header into tests/run_dist_tests.html, appends the single dist.js file instead, and adds the test scripts to that one too. Two pages, one run against the sources and one against the built artifact, both opened in a browser. The documentation target points at a ./jsdoc-toolkit directory, which is why the repository carries a .gitmodules file, and the npm test script exists only to forward to this make target.

Build output is committed, and the last commit is from 2021

The top level of the repository contains the built files next to the sources: dist.js, dist-unminified.js and dist.d.ts all sit in the root, alongside src, tests, scripts, docs, the Makefile, both license files and the manifests for npm and git. Committing build output is unusual for a JavaScript project and it has a practical consequence, since a consumer reading the repository rather than the registry can pick up an artifact that was generated at some unknown point rather than from the current sources. The project states its purpose plainly, saying the main purpose is to support the built-in client for BeeHub while attempting to follow webDAV RFC 4918, and that contributions implementing features of that and other webDAV standards are welcome. The last push to master is dated 2021-04-28 and the repository publishes no releases, so the published version numbers will not tell you how current anything is.

Editorial conclusion

Take this library if you need webDAV in a browser page, want no dependencies and no bundler in the chain, and are willing to link files in a fixed order. Do not expect a maintained package: the last push to master is dated 2021-04-28, there are no GitHub releases, and the version in package.json has been 1.0.0 for that whole period. Before you consume it from npm, check two things, because both are cheap to verify and both are easy to miss. The typings field is misspelled, so your toolchain may not find the type definitions at all, and the license is stated differently by the repository metadata and by the package itself.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases