Skip to content

Conversation

@GwynethLlewelyn
Copy link

Hi there! 👋

Since the last time I used tinify-go, TinyPNG has introduced two new file types to compress to — WebP and, more recently, AVIF. Their API didn't change, but tinify-go needed to allow these extra file formats to remain u

I also needed some sort of command-line tool to test the package! With a good reason: I have several PNG files to compress — and the compression to WebP or AVIF is simply phenomenal! — but many of these are bigger than 5 MB in size, which means that I can't upload them via the TinyPNG interface. But the API has no such restrictions! The files can be of any size; it's just that the number of monthly requests (on the free tier) is constrained.

That was an incentive to grab one of those many CLI-building packages (I originally picked urfave, which has often been forked and re-used in several popular packages), but I got hopelessly tangled in its convoluted way of dealing with flags specifically assigned to commands, and nothing worked! I almost gave up then, and it took me quite some time until I had this suddenly pressing requirement to use the TinyPNG API again... so I scrapped my earlier work and started from scratch.

I'm well aware that the 'example' command-line I've done is quite horrible! It's practically functional programming using global variables for almost everything — non-idiomatic Go at its worst. I know! It could — it should — be so much better, but, unfortunately, I was really in a hurry. So please consider this just to be a very crude prototype, to show what could be done; it also attempts to exemplify how the tinify-go API is supposed to be used.

I didn't do any thorough testing, just the basics, so don't expect full functionality for now. Two things are missing: the ability to add a background colour on transparent images (the API allows that!), and a way to retrieve how much credit (the number of requests left for the month) is still available on our account. This is returned as a header on the response body, but I haven't changed tinify-go to retrieve it. That's probably for a future development...

Another change was the introduction of a way to define a (HTTP) proxy to be used with tinify-go. This is purely optional, of course; but since I do use a proxy server running on my NAS at home, I wanted to use it as well in the command-line tool. It does several checks to figure out where the proxy server is supposed to be set, falling back to getting it from an environment variable (usually named http_proxy or some variant; this was never turned into a standard, unfortunately). I have only tested with Linux and macOS, but I guess it should work under Windows as well.

Speaking of which... I'm also reading the environment variable TINIFY_API_KEY using godotnet — this will also look for an .env file where that API key may be safely placed, away from prying eyes, and allowing automated CI tests to be created using the command-line tool, for simple pipelines. The CLI is supposed to allow images to use pipes into stdin/stdout to chain several commands together, but I haven't tested this very thoroughly.

Feel free to go through the changes and additions, and correct the code as much as you wish!

… because the API requires it!
This is just syntactic sugar for Go to compile the “local” module as if it were the “real” module.
Not even worth a commit.
… but added some info regarding the CPI example, too.
It’s not really used and should probably be abolished.
If error, return is a valid integer with 0. Since we deal with image sizes here, a size of zero is by no means acceptable upstream.
Minor cleaning up bugs required but that’s IT.
… and I forgot all about that
Also: added more debug messaeges
This is to make the directory structure more consistent with Go practices (see `go test help`)
As suggestd by ChatGPT.
… now, there it goes, in spades!
There is still a lot left to fix…
(e.g. for resize with scale, only width OR height can be non-zero, and the missing dimension should be skipped)
Seems to work, according to the tests!
@GwynethLlewelyn
Copy link
Author

This got closed because I pulled that branch from my own code.

While the original PR comment is still relevant to a degree, the 'new' code uses urfave/cli again (I have abandoned my own futile attempts of doing a CLI framework).

The new PR is now #8, and it totally replaces this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant