Open PullJosh opened 4 months ago
PullJosh
commented
4 months ago Still some big hurdles to get this to work, but hey it's pretty neat!
scratch-paint has some older dependencies that don't play well with new React (I had to pretty aggressively apply --legacy-peer-deps), so this is by no means a perfect solution, but it might be the best one.
towerofnix
commented
4 months ago Could we have a go at forking scratch-paint to modernize it in particular? LOL
PullJosh
commented
4 months ago @towerofnix I considered that! It's definitely not the worst idea. I don't like the idea of maintaining a fork, but scratch-paint probably won't be changing much in the near future anyway. Maybe I'll give that a go...
towerofnix
commented
4 months ago If Scratch 3.0 weren't hopelessly dependent on its modules basically staying in dependency-synch with each other, we could file a PR with any of the modernizations we make (provided no API changes obviously). But, well, Scratch 3.0 demands its modules basically stay in dependency-synch with each other, soooo. 😅 A fork is probably the best way. Merging upstream changes, if any, hopefully won't involve super significant work.
PullJosh
commented
4 months ago I've been taking a stab at modernizing scratch-paint: https://github.com/PullJosh/scratch-paint
I got all the dependencies updated, which feels great. However, I also took a stab at switching to TypeScript, which I think I regret. It makes my fork way different from the original repo without providing enough benefit to be worth it. (I really dislike writing pure JS, but the tradeoff doesn't seem worth it here.) Currently, most files are in TypeScript and it works at runtime but there are tons of type errors.
In retrospect, I wish I had just created a .d.ts file so that users of the package could get types without using types internally. I'm wondering if it makes sense to start over with a new repo and keep it JS but copy over the new code and dependency updates.
towerofnix
commented
4 months ago Yeah! Wow. I kind of think that just writing a .d.ts could make your life quite a bit easier... part of it is that modernizing just the dependencies means you can still bring in any upstream changes with relatively minimal effort, as long as they aren't counting on the behavior of those older dependencies.
If you despise writing JavaScript but a .d.ts offers essentially all the same benefits once you get to take your hands off the project, then prob'ly that'll work out nicer!!
Maybe from a new or reset fork instead of a brand new repo? (Like putting your current work on a different branch than master/main.) That way you keep the commit history and GitHub repository relationship ✨
PullJosh
commented
4 months ago Maybe it makes sense to create a new fork within the leopard org and then manually copy over my changes but without the typescript?
One option would be to use Scratch's paint editor. Another would be to find some other open-source editor to use. It does not make sense to build our own.