klipse: the tags stopped in 2022 while the manifest reads 7.12.0

The tags stopped in 2022 while the manifest reads 7.12.0

Three releases appear in the list. v7.10.6 is dated 2021-02-07, v7.11.3 is dated 2022-01-29 and v7.11.4 is dated 2022-01-30, so the two newest are a day apart. The version string in package.json is 7.12.0, which is above every tag on record, so the version the package declares was never released under that name. Commits did continue after the last tag: the repository was last pushed on 2024-10-01, roughly two years and eight months after v7.11.4. It is not archived. For anyone vendoring the plugin this matters, because the tag history and the declared version point at different points in the file's life and there is no tag to fall back on when a change needs reverting.

The embedded script comes from a storage bucket, not from a package

The integration instructions never reference a package. They reference three URLs, all on a Google Storage bucket: a CodeMirror stylesheet at `https://storage.googleapis.com/app.klipse.tech/css/codemirror.css` and two plugin builds, `plugin/js/klipse_plugin.js` and `plugin_prod/js/klipse_plugin.min.js`. So the code that runs on a reader's page is fetched from a bucket the project controls rather than from the npm tarball or from the repository tree. The package manifest is a separate artifact with its own entry point, `main` pointing at `klipse_plugin.min.js`, and that filename does not appear at the top level of the tree, where the built output sits inside a `dist/` directory. So the manifest's declared entry point and the file the blog instructions actually load are resolved through two different paths.

The minified build cannot serve Clojure snippets

Two script URLs are given and they are not interchangeable. The instruction for Clojure points at the non-minified build, and every other language is told to use the minified one. The reason is stated in a note rather than left to be discovered: for Clojure interactive snippets the non-minified version is required, because self-host ClojureScript does not support advanced compilation. That is a real functional boundary rather than a size preference. A blog that shows both Clojure and Python snippets therefore has to load the larger build, and the choice of which file to serve is the first thing to get right when integrating. The file also mentions hosting the tag from your own server, and points at a section for using older versions.

Configuration is three ordered steps and the settings key changes shape

Setup is described as three steps, and the ordering is part of the requirement rather than a suggestion. The page needs a doctype at the top and a utf-8 meta tag immediately after the head, the stylesheet and a settings object have to come before the script element, and the script element goes at the end of the body. The meta tag is called out as needed for the CodeMirror elements to display properly. The settings object itself is where the examples diverge:

<link rel="stylesheet" type="text/css" href="https://storage.googleapis.com/app.klipse.tech/css/codemirror.css">

<script>
    window.klipse_settings = {
        selector_eval_js: '.language-klipse-eval-js', // css selector for the html elements you want to klipsify
    };
</script>

The general and JavaScript examples use the key `selector_eval_js`, while the Clojure example uses a plain `selector`. The text says the keys are per language, so the shape changing between examples is expected rather than a mistake.

npm test exits with a failure, and codemirror is the only dependency

The package manifest has one script and it is a placeholder. Running it prints an error saying no test is specified and then exits with status 1, so the command exists and always fails. There is no other test entry point in the file. Dependencies are equally thin: a single entry, codemirror, with a lower bound of 5.58.2 and no upper bound, so a fresh install resolves to whatever the newest matching version is at the time. Everything else the plugin evaluates, from Opal to Pyodide to Yaegi, is either bundled into the built file or fetched separately, and none of it is declared as a dependency. A consumer pinning versions has nothing to pin against except one open range.

Six build definitions sit at the root for one plugin

The tree mixes build systems rather than choosing one. There are two ClojureScript build definitions, `plugin.cljs.edn` and `plugin_prod.cljs.edn`, which line up with the two script URLs the integration section gives. There is a `deps.edn` and a `dev.cljs.edn` for the Clojure CLI, a `project.clj` for Leiningen, and a `figwheel-main.edn` for a third development path. On the JavaScript side there are both `package.json` and `bower.json`, so two package managers are declared for the same component. The naming of the two plugin files is the clearest evidence that the dev and production builds are separate products rather than two bundles of one. Contributor tooling sits alongside them too, with an Emacs project file, a pull approval configuration, a dependency graph image and a separate contributor document.

The manifest names three languages the language list never mentions

The two lists do not agree. The supported-language section names seventeen targets: JavaScript, Clojure and ClojureScript, Ruby, C++, Python, Python3, Scheme, Prolog, Common Lisp, PHP, SQL, Lua, Go, Brainfuck, JSX, EcmaScript2017 and Google Charts. The description in package.json names thirteen, and among them are OCaml, Reason and Reagent, none of which appear in the section list. Going the other way, the section list carries Python3 through Pyodide, Prolog through Tau Prolog, PHP through Uniter, SQL through sql.js, Lua through wasm_lua and Go through Yaegi, and none of those six appear in the manifest description. So the npm summary is both missing languages that work and listing three that the documentation does not claim.

What runs in the reader's browser, and it includes eval

The evaluation model is the part to understand before embedding this on a page. The file states plainly that evaluation happens in the browser and that no server is involved at all. For JavaScript snippets the mechanism is the JavaScript `eval` function, with result pretty-printing handled by a separate formatting library. Every other target is delegated to a named in-browser engine: Opal for Ruby, Skulpt for Python, Pyodide for Python3, BiwasScheme for Scheme, Tau Prolog for Prolog, JSCL for Common Lisp, Uniter for PHP, sql.js for SQL, wasm_lua for Lua, Yaegi for Go, JSCPP for C++, and self-host ClojureScript for Clojure. Editing inside the snippets is powered by CodeMirror. That means a snippet in a post executes in the page of whoever opens it, which is the intended behaviour and also the whole of the security surface.

Editorial conclusion

klipse fits a documentation or blog that wants readers to edit and run snippets without a server, and the seventeen language targets are the reason it is still worth looking at. Verify four things first. Pin your asset URL, because the plugin and its stylesheet are served from a Google Storage bucket rather than from a package you control, and the bucket is not versioned by the tags. Read the release dates before assuming a fix landed: nothing has been tagged since v7.11.4 in January 2022, and the repository was last pushed on 2024-10-01. Decide which build you can use, because the minified script cannot serve Clojure. And settle the dependency surface yourself, since npm test is a placeholder that exits with a failure and the manifest pins nothing exactly.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes