1.5.0

ESM support 🚀

While trying to utilise the initial version of phraze module, a sudden realization shocked me. There are people out there who are writing pure ESM nodejs projects, and they do it as it is the most natural thing to do !!!

Despite having fairly painful memories of the UMD (universal module definition) / AMD (asyncronous module definition) / ESM (EcmaScript Modules) / CJS (CommonJS) jungle, I tried to give it another go.
Long story short, it's still far from obvious, but now things are a bit simpler that they once were. ESM seem to have won the heart of the many (in the frontend, it had mine already), on top of being anointed by the holy tc39 by definition.

The main difficulties I've encountered while working on ESM support were:

• TS being bitchy about the export syntax. To be able to keep the "require" syntax everyone loves, I had to use a little hack
• Tests duplication. There was no way I'd rewrite & maintain 30+ more tests. So I made an utility that write those tests for me, and that was very fun! 10/10 would write JS with JS again
  For the record, this is the 3rd iteration; before that I had a sweet (but hard to maintain) AWK version, then a glitchy awk-in-js one.
• jest experimental ESM support. Had several back & forth with babel & ts-jest configs before having a working setup. Fortunately, the size of Jest community, and the quality of it's issue contributors, made it so I could find a working setup without having to dive into their source code. Thanks guys !

Ditch remap-istanbul

GitHub was very annoying flagging me for security issues about this thing absolutely no one interacts with besides me, but yeah. While I had to update Jest to support ESM, I took the chance to ditch it, and generate the coverage report with Jest. Cya remap-istanbul! 👋

1.4.0

• Closes Support chevereto issue after more than eight months.

Sorry for the wait! It was partially caused by a massive amount of yak shaving around Chevereto CI, like, writing a pure Docker stack, then switching to handmade docker-compose, then to remotely-hosted K(uwu)bernetes stack, all while knowing overall little about Docker & nothing about K(uwu)be

"TDD is a time gain, not a time loss", they said !!!

Well, maybe it's not wrong in the end. Afterall the back and forth allowed me to learn important things about TLS and networks and stuff. And there's no debate about the future developments/bugfixes being made easier!

Some other things that took time was hesitating on the interface. In the end I opted for something that felt balanced between TypeScript constraints, flexibility and ease of use.
I hope Chevereto users will like it, whatever the version they're using! Either way I'm all ears for feedback.

• Switch from Travis CI to Github Actions

Travis CI today is far from the one I once knew and loved. No hard feelings, but I have to move away to a more OSS-friendly solution. I went with GitHub Actions. For my limited usage it feels like the old Travis: a free, easy to setup, pleasant to use automation solution.
Maybe one day I'll also automate the npm publish stuff with it, seems simple enough.

1.3.5

• Remove useless dependencies
  I don't know how eslint stuff came here oO

1.3.4

• Better error handling
  This issue made me realize how wrong was my error handling. Now checking for response.error and returning it if defined. No more "faulty payload" generic (& incorrect) error for imgBB API-related errors (like 'file too big' or 'invalid API key')!

• Small fix: passing non-number to expiration param should throw a proper Error

• Chore: npm audit fix to please secoority bots, even if I'm the only one concerned by devDeps and even if nothing had any chance of happening ^o^

• Run tests in parallel: npm run dev run was too long
  To achieve concurrency I took the easy route of splitting the test suite into separate files. It's not DRY, not very clean (and GitHub will shame me by displaying more JavaScript % than TS) but I read enough bad stuff about Jest test.concurrent to prefer the reliable (and easy) route for now.
  npm run dev is still longer than ever thanks to absolutely inefficient src/__tests__/require/bigFileExplicitThrow.js relying on monkey-developed (thats harsh on monkeys) dependency, but I don't mind since the output of other tests comes faster.

• Next milestones are: minimizing bundle size, and supporting chevereto-based APIs, hopefully before 2022 !

1.3.3

• Add encodeURIComponent on the name that is passed. This revealed the weird transformations imgBB API could make on passed name. A future version will come to better check the compability of passed name with imgBB, and either warn or reject in case the exact name can't be accepted as is by imgBB.

• Feat: passing an image URL is now feasible as it should !

• Chore: fileToString func now calls fs.promises.readFile instead of wrapping fs.readFile into a Promise: afaik it won't change the behaviour in the end, it's just more readable that way, & makes the async nature of that operation even more obvious (reminder: the syncronous fs.readFile call blocks the holy Event Loop 'til it is complete)

• TODO: continue the UX work that has been started. This implies, amongst other things, making extra sure (writing a test for it?) that the ResponseObject interface is easily accessible; update the "compatibility" section (I'm transpiling to es5 atm); better input validations (imageUrl regex, name parsing...); audit performance (could it be improved further)

1.3.2

• Patch responseObject interface
  Fix the interface for medium key & update README for that matter.

• Update devDependencies For sport, I tried to please npm audit & GitHub dependabot for dev deps. Fixing the bothering RCE vulnerability took a remap-istanbul fork since their repo last commit is 3 years ago.

• One day tho, I should setup a proper Istanbul CC setup & take the opportunity to replace tslint by typescript-eslint since the former is deprecated since 2019.

1.3.1

• Updated responseObject interface
  Thanks for PR :)

• While being at it, I had some fun with code coverage, tweaked some package.json scripts and gave a cleaner name to "rebuild.js".
  Intrigued about it, I tried Jest's built-in coverage report, but it pointed to ugly, transpiled JS. Saw two ways to fix this: a parallel Istanbul setup to handle it, or hacking around to make it work with Jest built-in tool. For funsies I took the latter route using remap-istanbul.
  Their readme says: We strongly encourage developers to leverage IstanbulJS, and only use this package (remap-istanbul) when needing to support legacy versions of Istanbul.
  In my case, it seem the Istanbul version in Jest's depencency graph is 0.x, so I opted to use their module for now and leave in-depth Istanbul for later.
  Note: node kept complaning about undefined "VERSION" and circular dependency while running npm run remap, so I ended using --no-warnings flag for it. If curious, feel free to make it --trace-warnings in package.json ;). In the end, it allows to generate two HTML coverage reports after a test pass, one for transpiled code (./coverage/lcov-report), one for source (./coverage/ts-report).

  • Increased code coverage: 98.46% statements covered. Tests will never enter the ".on('error', () => )" callback in the POST function, but I'll feel safer leaving that block. It's not like it's hurting anybody anyway ^o^

  • Updated CONTRIBUTING to reflect that.

1.3.0

Issue #6 brought an interesting feature idea. Took a bit of time because I first had to adapt the module used by the tests (waifu-generator owo).

Everything seem to work as intended.

Took the opportunity to reduce insanity within test code. Not perfect, but still less horrible than before.

Finally, I'm abandoning the idea of making this frontend-compatible some day. I don't want to endorse terrorism, and it's definitely not reasonable to encourage people to throw API keys into their frontends (even free API key - remember this module will stop working the day imgBB stop providing their service).

What I could do, aside writing this in the README, is perhaps redirecting to a working HTML/JS or React snippet, so people looking for a quick solution without any regard for security (for POC/hackathon/pet project) could gain some time.

1.2.0

While issues #3 and #4 were closed by users, they still needed to be adressed.

It's now possible to pass 'expiration' and 'name' params to imgBB API through an options object.

Also, the design of the test was terribly, terribly wrong (I always upload the same file, but imgBB API, by checksum or something, is able to tell, thus always returns my original upload as response. I didn't noticed until toying with name & expiration params, but the test were little more than dead code).

Fixed by making each test generate a random image (wrote another module for that), enabling proper testing for the new option object, & overall increased sanity.

Took the opportunity to write a few more tests; not nearly as rigorous as they should be, but still better than the imgBB API ping of old.