Minify ansi_up.js file

[dosisod]

Currently the ansi_up.js file in the root of this project is about 23KB. Providing a minified version of this file would be nice so that you don't have to vendor and minify the file yourself.

In my testing I was able to get the file size down to 9.2KB using esbuild:

$ esbuild --minify --loader=ts < ansi_up.ts > ansi_up.min.js

$ ls -alh ansi_up.min.js
-rw-r--r-- 1 loot loot 9.2K Apr 21 16:18 ansi_up.min.js

This is an improvement, but looking at the file you'll find that there is a lot of whitespace due to the rgx and rgxG templates:

"use strict";var PacketKind=(r=>(r[r.EOS=0]="EOS",r[r.Text=1]="Text", /* SNIPPING */ rgx`
                        ^                           # beginning of line
                                                    #
                                                    # First attempt
                        (?:                         # legal sequence
                          \x1b\[                      # CSI
                          ([\x3c-\x3f]?)              # private-mode char
                          ([\d;]*)                    # any digits or semicolons
                          ([\x20-\x2f]?               # an intermediate modifier
                          [\x40-\x7e])                # the command
                        )
                        |                           # alternate (second attempt)
                        (?:                         # illegal sequence
                          \x1b\[                      # CSI
                          [\x20-\x7e]*                # anything legal
                          ([\x00-\x1f:])              # anything illegal
                        )
`)
/* SNIPPING */

By manually removing the comments and whitespace from the templates I was able to get the file size down to 6.5KB:

$ ls -alh ansi_up.min.js
-rw-r--r--   1 loot loot 6.5K Apr 21 16:23 ansi_up.min.js

Manually minifying the templates for each release would be a pain though, so perhaps changing how the rgx functions are called would be a better option (perhaps by using string concatenation or de-indenting the whitespace).

I have no issue manually minifying the file for my own project, but having a minified version that others could use would be nice. I don't know what the release process looks like for this library, but I would be more than happy to write a build script that automates this minification process.

Thanks!

[drudru]

Hi,
Sry to be late to this.
How big is your minified version vs. un-minified when the web server sends it as a compressed payload?

[silverwind]

Imho, minification is best left to be done by the consumer via their bundler (esbuild, vite, webpack, etc).

If you are really nice, you could publish a minified file in the npm package, but it needs additional tooling.

[dosisod]

@silverwind The issue is that esbuild cannot minify the rgx template functions since they use string literals, which are stored as-is. A compiler cannot safely minify this, but since I know that the rgx function uses a regex to remove whitespace and comments, I know I can minify it safely (by hand, that is).

And @drudru here are the stats you where looking for:

File	Size	Size gzipped	Notes
ansi_up.js	15422	3285	Transpiled .js file
ansi_up.min.js	9530	2501	Minified .js file
ansi_up.min.min.js	6757	2163	Minified, optimized rgx and rgx0 strings

I used the following Python code to get these results:

from fastapi import FastAPI
from fastapi.staticfiles import StaticFiles
from fastapi.middleware.gzip import GZipMiddleware

import uvicorn

app = FastAPI()
app.mount("/", StaticFiles(directory="files"), "static")

app.add_middleware(GZipMiddleware, minimum_size=512)

uvicorn.run(app, host="0.0.0.0", port=8000)

And used curl -i --compressed localhost:8000/filename_here | grep content-length to get the gzipped size.

[silverwind]

Okay, I think at least these rgx strings should be put in minified variant into the source here, the rest can be done with a minifier on the user side.

[drudru]

Wow @dosisod - excellent work.
I'm kind of shocked that the compressors are not able to easily handle the whitespace.
Still, less than 400 bytes. I suspect it is the comments in the strings.

The next major release will be about moving to the module format, API enhancements, and other tiny features.

Once that is out, work will be done on this a minor number release.