[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ELPA submission: mathjax.el
From: |
Augusto Stoffel |
Subject: |
Re: ELPA submission: mathjax.el |
Date: |
Wed, 23 Oct 2024 17:28:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
On Wed, 23 Oct 2024 at 07:02, Stefan Kangas wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> More specifically, there's a 2.3 MB minified JavaScript file that is
>>> committed to the repo and I will take care to update when the "real"
>>> source (also in the repo, of course) changes.
>>
>> Is there any reason to choose the minified version? Also, do you know
>> if you could support KaTeX as well? AFAIK it is more lightweight
>> (though the package name might be confusing in that case).
>
> I don't feel comfortable with distributing a 2.3 MB minified JavaScript
> file, unless it is generated from source code either as part of the
> package build process on GNU ELPA,
Ah sure, what you suggest is of course much better -- I didn't think
ELPA might be capable of building stuff. Either of those would be
possible in my case:
A. If the build environment has Node/npm, all that is needed is to run
make math2svg.js.
B. If the build environment can run containers, I can include a suitable
Dockerfile.
> or during the package installation on users' machines.
This is not an option in my opinion. It doesn't "just work", instead
requiring the user to execute a build step, and the download is 40 times
larger than the minified JS.
> Could we work on resolving that?
I'd be happy to. If neither options A. or B. are currently available, I
would say implementing B. is a good approach in general for packages
that require a build step.
Re: ELPA submission: mathjax.el, Augusto Stoffel, 2024/10/23