guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jelle Licht
Subject: bug#27049: [PATCH] gnu: Add mathjax.
Date: Mon, 29 May 2017 14:26:11 +0200



2017-05-29 14:05 GMT+02:00 Ludovic Courtès <address@hidden>:
Jelle Licht <address@hidden> skribis:

> 2017-05-29 11:34 GMT+02:00 Ludovic Courtès <address@hidden>:
>
>> Arun Isaac <address@hidden> skribis:
>>
>> > Ludovic Courtès writes:
>> >
>> >> Also, Arun: is this package really source code?  Or does it contain
>> >> “minified” code and also bundles all its dependencies (which would not
>> >> be okay)?
>> >
>> > Good question! I had assumed it was the full source code without
>> > checking carefully! I checked just now. The full source code is in the
>> > "unpacked" directory of the tarball. The code in the top level directory
>> > of the tarball is minified code. I think we should install only the
>> > minified code to share/_javascript_/mathjax/.
>>
>> Yes, but we should treat minified code as “object code”: we’d remove it
>> in a snippet and then minify from source.
>>
>> ISTR that the common minifiers depend on a lot of Node packages, so this
>> may be a can of worms.  Maybe Jelle or Chris or Dave know more?
>>
>
> The minifiers I use for work are usually designed as a plugin in a bigger
> node packages, so they suffer from the bootstrap problem lots of node
> packages have if you want to build them from source.
> Maybe we could look for a smaller, standalone minifier package that we
> could use for all minification needs in guix? I always used uglify-js from
> before my guix days, so I am not sure how workable it would be to package.

What smaller, standalone minifier would you suggest?  :-)

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.

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.
 

Ludo’.

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.

- Jelle



reply via email to

[Prev in Thread] Current Thread [Next in Thread]