wilsonzlin / minify-html

Extremely fast and smart HTML + JS + CSS minifier, available for Rust, Deno, Java, Node.js, Python, Ruby, and WASM
MIT License
832 stars 36 forks source link

Please provide a docker image #30

Open tacone opened 3 years ago

tacone commented 3 years ago

Providing a Docker image on Docker Hub may allow users to grab the latest binaries via a multistage build without the need to hit your website every time they build.

fatheyabdelslam commented 3 years ago

i can't install it on docker !!

wilsonzlin commented 2 years ago

Adding another build variation is probably too much (especially an entire Docker image for a tiny self-contained tool), and I think this can trivially be done manually anyway, by either copying the binary into the image or building from source if desired.

polarathene commented 2 years ago

Adding another build variation is probably too much (especially an entire Docker image for a tiny self-contained tool)

It would actually provide a CLI equivalent option that is supported across platforms, instead of requiring to pull a platform specific binary from releases, everyone could use the same Docker image. That's useful for users.

It's also useful for you, as you can ensure you release the CLI tool with a much more reliable way to reproduce a testing environment, and run your tests against that in the CI.

The current x86_64 linux binary 0.9.2 outputs nothing when I tried it 0.9.2-linux-x86_64 index.html. While building from source works. I don't know why that is, but if you produce static builds for linux with musl you'll also have a more portable binary on linux. This issue has happened before for the project on a different platform.

Perhaps it's due to the CI building from Ubuntu 18.04?:

https://github.com/wilsonzlin/minify-html/blob/284f908c3274f912b2e913a299e9296f17226386/.github/workflows/cli.yml#L14


I think this can trivially be done manually anyway, by either copying the binary into the image or building from source if desired.

Building from source isn't immediately obvious for others. I'm used to building a rust project, but was a bit confused about needing to run a script that uses NodeJS to prepare that build, especially since this project has multiple other build variants unrelated to the CLI including a NodeJS package.

When the binary isn't working like in my experience, copying it into the Docker image isn't going to be very helpful. It's far better when your project automates the build for releases with a Dockerfile, where you're able to publish an official release on DockerHub that is trusted, and tested by your own CI.

You could then take the binary built from the image to distribute directly for Linux if you like.

wilsonzlin commented 2 years ago

Thanks @polarathene, those are good points raised. I'll reopen this issue for tracking the Docker image.

I've had issues in the past with cross-platform compatibility due to glibc (#12 #25 #78 #79 #88), but was required to target it due to bundling with esbuild-rs which includes the Cgo runtime and requires glibc. Now that I've replaced it with a Rust-based JS minifier I wrote from scratch, it should be possible to target musl and create fully static CLI binaries.

Note that the issue mentioned (#6) was due to a bug in the parser itself, not the underlying libc and platform issues.

hoijui commented 7 months ago

I wanted to add, that a docker image is also useful for running the tool on CI, which could make sense for anyone that uses static site generators on e.g. GH Pages, as a post-processing step, and .. that is a huge potential clientele!

MaartenUreel commented 4 weeks ago

I wanted to add, that a docker image is also useful for running the tool on CI, which could make sense for anyone that uses static site generators on e.g. GH Pages, as a post-processing step, and .. that is a huge potential clientele!

Not only for static sites. In our Django websites, we minify the HTML during the build step. So our templates are full of comments and other useful stuff, but when deploying, we use html-minifier to reduce the size of all templates and especially remove all our internal comments.

for HTML_FILE in `find -type f -name "*.html" -not -path "./node_modules/*"`
do
    npx html-minifier --collapse-whitespace --remove-comments --remove-tag-whitespace --minify-css --minify-js --ignore-custom-fragments '[/{{[\s\S]*?}}/, /{%[\s\S]*?%}/]'  -o "${HTML_FILE}" "$HTML_FILE"
done

Furthermore we also validate this step with a pre-commit stage:

  - repo: local
    hooks:
      - id: html-minifier
        name: validate HTML minification
        language: node
        additional_dependencies:
          - html-minifier@latest
        entry: html-minifier
        types: [html]

All this was very easy to set up because the CLI is available with a simple npm install.

For now we decided to stick to html-minifier for that...