bug#27049: [PATCH] gnu: Add mathjax.

[Ludovic Courtès]

Jelle Licht <address@hidden> skribis:

> That is an interesting question. A cursory glance at the uglify-js leads me
> to believe it could probably be packaged. The standard node-in-guix issues
> apply though:
> - We do not have a test framework packaged, so running tests to verify that
> packages actually work is going to be difficult.
> - We end up with a bare-bones package, as some features require problematic
> packages (in this case source-maps seems non-trivial to get packaged, due
> to a dependency on webpack). The package itself does not have knowledge of
> these issues though, so any attempt to use these unsupported features would
> lead to a crash.
>
> The second point is less of an issue if this minifier packages is only used
> internally as part of a build process.

OK.

> Another issue with minifiers in general is that is Very Hard to write a
> proper minifier. If we choose to not use the minifier as expected by the
> package author, we will at some point run into issues that will be very
> hard to report and get fixed upstream, as it will only be us experiencing
> these issues due to our ... unique .. build procedure.

Sure.  My suggestion would be to use an existing, established minifier,
only one that is relatively simple to package.  It could be one written
in a language other than JS (Ricardo mentioned ‘cl-uglify-js’ on IRC),
or it could be a simplistic minifier written in JS but with very few or
not dependencies, if that exists.

> Maybe some sustainable progress could be made by abusing pars of guile's JS
> frontend?
> The process could go like this:
> JavaScript source -> AST -> minify identifiers, tree shakers etc ->
> Serialize AST to minified .js file.

That would be an interesting exercise, but probably a more risky
approach.  :-)

Ludo’.