Is this repo still maintained?

[michael-letcher]

Is this repo still maintained?

There are many tickets and pull requests that have been ignored.

If so, is anyone interesting in branching off and creating a new package with pulling in a number of the pull requests?

[thedustinsmith]

This is a good question.

I agree that are a lot of great fixes and PR's open. In contrast to those, there are also a lot of questions in Github that are better suited for StackOverflow or some sort of help forum that I don't have time to monitor.

In my eyes, the biggest problem Croppie has right now is a lack of tests. Every time we merge a PR, Croppie gets a few more errors that overwhelm the Github feed. If we had tests to prevent that, I (or someone at Foliotek) would be much more eager to merge in PR's that include new features, or address zooming issues, or work on documentation, etc.

@michael-letcher Do you or does anyone you know have interest in writing tests for an open source project? It should be a relatively small test project, and I could even provide you with some test scenarios that have been big pain points in the past.

[michael-letcher]

@thedustinsmith

I agree that there are many tickets here that are more suited for Stack overflow and with some minor moderation within this repo we could reduce the tickets to get a better view of the what the key issues are.

I would be interested in assisting in writing these tests.
Using Mocha or Jest (might be better for smaller project like this) and perhaps moving to Typescript would better help in avoiding further bugs.

[thedustinsmith]

@michael-letcher

Here's my impression of the key issues of present and past based on keeping my eye on Github's ticket feed:

• Zooming - People have a huge problem with the zoom configuration. I agree it's not ideal, but i haven't seen a proposal that doesn't clutter the API or that stands out as the answer. However, I haven't really thought about (or searched through comments regarding) this issue in a while. This isn't something that's test critical at the moment.
• Rotating - This was something that was added afterwards and has added so much complexity that it's a pretty big pain point concerning bugs. Regarding rotating people are concerned with:
  • The same portion of the image is still within the viewport when you rotate.
  • The resulting image has the same rotation
  • The image doesn't go outside of the boundary when rotated
• Along with Rotation is Exif - If an image has exif data, we need to maintain that rotation, ideally even the exif data
• Boundary Enforcement - this is another one that added a lot of complexity. enforceBoundary wasn't in the original definition of Croppie, and since it's been added a lot of bugs have popped up related to it.
  • Need to check that if boundary enforcement is enabled the image doesn't leave the viewport.
  • If boundary enforcement is disabled, then the resulting image is the expected result. To be honest, at the moment I can't remember the expected result. If the image should always be the width of the viewport or if it should be the dimensions of the visible portion of the image.
• Image sizes - When cropping images that don't meet the minimum width/height requirements to be shown within the viewport, we've had some problems with that in the past.
• General Results - I would say my definition of general is definitely arbitrary, but the way croppie was initially designed is to have enforceBoundary: true, no rotation, default zoom parameters.
  • This typically doesn't break except in extreme circumstances, but I would think this would be a good circumstance to test as well.

There are certainly other issues besides these, but if we have tests in place for these issues, addressing less common issues will be much easier in the future. As it is I can't find the time to work on Croppie, because I know every change needs to be hand tested and will inevitably cause issues for someone else's parameters without tests in place.

Regarding Typescript, I agree, and there have been some PR & issues expressing interest in this. My position is I'm a little uncomfortable rewriting the library in typescript before having tests in place that ensure that these workflows aren't broken. But I understand the chicken & egg problem, tests might be easier to write with TS in place. What are your thoughts on writing tests before TypeScript is in place?

[michael-letcher]

@thedustinsmith Okay,

I'll move to Typescript as that will help me in understanding the code quicker using #603 as a base.

I'll also add Babel (to compile TS for Jest to test) and begin creating base.

You can track my progress in my fork.
https://github.com/michael-letcher/Croppie/tree/rebuild

[theodorejb]

I developed a fork named Cropt which is written in TypeScript, has a simplified API, and improves image scaling quality: https://github.com/theodorejb/cropt.

[michael-letcher]

Awesome work @theodorejb I sadly never finished my revamp, seems it's also disappeared too which is odd.

Glad someone else picked it up