-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Would you welcome a typescript version? #58
Comments
Hi Kyle, Yes, we would be interested in a TypeScript version. It would solve a lot of problems with trying to shoehorn the JS version into TS applications while keeping various type checkers happy. I worked on a TS version a few months ago, and made considerable progress. However, other things got in the way, and I had to put it to one side. It also became apparent to me that I'm the wrong person to make design decisions in TS since I have no expertise in this language. Here's what I have so far, maybe it would be a good starting point: |
@rgbkrk I'm not a maintainer here so this is only the opinion of someone who also uses the library. The task of rewriting in TypeScript seems like it would be a big enough change that it could be a massive PR hard to review and fully test. Did you try seeing how hard it would be to start by compiling the existing JS with the TypeScript compiler? Did it have an impact on the output size? Could it obviate the role that Closure Compiler plays? It seems like if we could make a case for introducing TypeScript into the build step for JavaScript then we could rewrite functions one at a time and slowly lean more heavily on the type safety. I'd at least be curious to learn from this kind of transition. |
Check out #74 for the current PR. |
I took the JS and converted to a properly typed TS version for one of our own projects. Took a few days but works well. The test I ran was a simple VSCode extension which can compare two texts.
Here is the PR #127 |
Right now I'm working with a vendorized copy of diff-match-patch as part of CoCalc's code base. I'm considering converting
diff-match-patch
to typescript as the rest of cocalc's repository is switching over to typescript.However, I view the source of truth for the implementation to be here in this repository (just like the npm package for diff-match-patch from @JackuB et. al. defers to here). Instead of modifying it "internally", I'd like to contribute upstream here.
I would assume we'd still make the compile target match what's documented in the wiki:
As part of this, I'd keep it closely aligned with
@types/diff-match-patch
.The text was updated successfully, but these errors were encountered: