Call for maintainers

[hipstersmoothie]

Today I worked with @oliver-moran to transfer the project to this org to continue the maintenance of jimp 🎉

A few years ago I reached out to Oliver and asked to be the steward of the project. This was a great first step in my OSS journey and I made a lot of improvements to the library. Some of those improvements look a little dated now but I have plans for that.

Maintaining this project on my own is HARD. There are a constant influx of issues. While I've tried in the past to bear this burden myself it's just not sustainable for any project.

Now that we have the repo in an org it's a lot easier for me to control the project and add other maintainers. If you think you'd be a good one feel free to add to this thread.

[dhanyn10]

interested, but my knowledge not enough 😢
you made several release just in hours. This gives me with a lot of email message 😆

[hipstersmoothie]

Had to get automation working on this repo. Currently updating and merging all the pending PRs too.

If you're interested a great place to start is just in issue triage. Seeing if you can recreate a bug is a great place to start.

If the dev docs aren't enough to get you up and running that's another great place for contribution. The tech stack here is a little old and I'm gonna do a lot of work to modernize it before modernizing jimp itself

[nopeless]

@hipstersmoothie Is TS rewrite a concern? If so, I am interested

Also a way to remove bad practices in this library

[hipstersmoothie]

Also a way to remove bad practices in this library

Yup 😄 If jimp is doing anything weird or non standard I want it gone! I'm not ready to start on that work quite yet, still want to get a lot of things in order.

Once I am ready I'm gonna create a next branch where everyone can go to town changing all the things that don't make sense.

Is TS rewrite a concern? If so, I am interested

I do also plan to do this once cleanup is done. I have a very specific picture of how I think it should work but I'm open to feedback. For that I'll open a separate issue.

[nopeless]

Also a way to remove bad practices in this library

Yup 😄 If jimp is doing anything weird or non standard I want it gone! I'm not ready to start on that work quite yet, still want to get a lot of things in order.

Once I am ready I'm gonna create a next branch where everyone can go to town changing all the things that don't make sense.

Is TS rewrite a concern? If so, I am interested

I do also plan to do this once cleanup is done. I have a very specific picture of how I think it should work but I'm open to feedback. For that I'll open a separate issue.

I'd definitely want Jimp to retain its monorepo structure but the modules are too modularized in my opinion

TS should have a long development (3+ months) and released as alpha for longer times. When TS is finalized, we test against latest major version of Jimp and deprecate it for good.

I also suggest we move from doing pure js manipulation to providing a higher level of plugins and text rendering capabilities while being more concise than HTML. We can achieve this by using sharp internally. For text rendering, we should definitely invest in ttf rendering.

Imo, we need to find place somewhere between raw image manipulation speed and html generation (Vercel's OG generation for example)

[hipstersmoothie]

sharp that goes agains the core of jimp. Share uses native tech to do its thing. jimp needs to run in a browser.

my vision for jimp is:

• fully type checked
• plugins build up the type naturally
• add wasm wrappers for png, etc
• ship those as more plugins
• ship a jimp-wasm that uses these image encoder decoders

I also suggest we move from doing pure js manipulation to providing a higher level of plugins and text rendering capabilities while being more concise than HTML. We can achieve this by using sharp internally. For text rendering, we should definitely invest in ttf rendering.

you should expand upon this in a separate issue

[nopeless]

sharp that goes agains the core of jimp. Share uses native tech to do its thing. jimp needs to run in a browser.

my vision for jimp is:

• fully type checked
• plugins build up the type naturally
• add wasm wrappers for png, etc
• ship those as more plugins
• ship a jimp-wasm that uses these image encoder decoders

I also suggest we move from doing pure js manipulation to providing a higher level of plugins and text rendering capabilities while being more concise than HTML. We can achieve this by using sharp internally. For text rendering, we should definitely invest in ttf rendering.

you should expand upon this in a separate issue

Oh, I have been using jimp for servers for a while. Totally missed that issue. Jimp wasm definitely sounds like a good solution to the speed issue. Which language are you planning to use?

Ttf rendering is a highly requested feature so I think we should work towards it

[hipstersmoothie]

I agree! better font support would be great!

[hipstersmoothie]

I plan to keep the project all typescript for now

[arackaf]

@hipstersmoothie Oliver added me as a maintainer way back when, so I'm getting all the notifications on the PRs you're merging - just wanted to thank you for your amazing work here. Stoked to see this project moving forward!

[danielholmes]

I'd encourage a gradual move to Typescript using the allowJs setting. You can start with less used plugins to see if there's any effects on the projects using this then slowly move to the more commonly used parts as there's more confidence about the migration.

[nopeless]

I'd encourage a gradual move to Typescript using the allowJs setting. You can start with less used plugins to see if there's any effects on the projects using this then slowly move to the more commonly used parts as there's more confidence about the migration.

I don't think this is the case here. With my experience with JS to TS migrations, there are a lot of incompatible js practices that make ts unergonommic. This is on the same token on my previous argument that a lot of api should be cleaned up

[hipstersmoothie]

I think the move here is a total rewrite. I agree that gradual is best most time but since we're a library we want an excellent TS api and the only way to do that is from the ground up. What we have now works for the most part and can keep working as we develop a next branch.

We should use the "builder" pattern that builds up the jimp type as you add plugins. This will make it so that all the manual typings aren't really needed.

At the same time I want to clean up the API surface of jimp. Some examples

• audit public API
• async instead of callback?
• change manipulation functions from args to options objects

[lekoaf]

Isn't this library almost already written in TypeScript? It's just a matter of applying the type definitions to the source code instead of separate files. And of course fixing the build system a bit.

That seems like the obvious first step, but I might be missing something since I don't have much knowledge about the code base. I'm "just" a user of the library in a TypeScript environment.

[hipstersmoothie]

Not at all 😅 The types were a herculean effort for @crutchcorn to come up with and need constant maintenance. I don't think we'll break the public api of jimp itself through the ts rewrite

details here #1189

[boneskull]

FWIW, starting with JSDoc docstrings and gradually moving to .ts sources is a viable way forward in lieu of a ground-up rewrite. We're doing this in Appium and have had success with it (we also use jimp).

[so1ve]

I'm interested in rewriting this library in TypeScript but I am not familiar to the APIs. However, I can do some basic work!