Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call for maintainers #1128

Closed
hipstersmoothie opened this issue Feb 3, 2023 · 17 comments
Closed

Call for maintainers #1128

hipstersmoothie opened this issue Feb 3, 2023 · 17 comments

Comments

@hipstersmoothie
Copy link
Collaborator

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
Copy link

dhanyn10 commented Feb 4, 2023

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

@hipstersmoothie
Copy link
Collaborator Author

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
Copy link
Contributor

nopeless commented Feb 4, 2023

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

Also a way to remove bad practices in this library

@hipstersmoothie
Copy link
Collaborator Author

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
Copy link
Contributor

nopeless commented Feb 5, 2023

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
Copy link
Collaborator Author

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
Copy link
Contributor

nopeless commented Feb 5, 2023

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
Copy link
Collaborator Author

I agree! better font support would be great!

@hipstersmoothie
Copy link
Collaborator Author

I plan to keep the project all typescript for now

@arackaf
Copy link
Collaborator

arackaf commented Feb 5, 2023

@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
Copy link
Collaborator

danielholmes commented Feb 5, 2023

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
Copy link
Contributor

nopeless commented Feb 5, 2023

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
Copy link
Collaborator Author

hipstersmoothie commented Feb 5, 2023

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
Copy link
Contributor

lekoaf commented Feb 6, 2023

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
Copy link
Collaborator Author

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
Copy link

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
Copy link

so1ve commented Apr 21, 2023

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

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

No branches or pull requests

8 participants