migrate Exn.Error to JsExn

[tsnobip]

No description provided.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@8036

@rescript/darwin-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@8036

@rescript/darwin-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@8036

@rescript/linux-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@8036

@rescript/linux-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@8036

@rescript/runtime

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/runtime@8036

@rescript/win32-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@8036

commit: c0c5eb6

[zth]

Great stuff! I'm guessing this is heavily LLM influenced? Regardless, was adding something to the migration tool easy enough?

[tsnobip]

Great stuff! I'm guessing this is heavily LLM influenced? Regardless, was adding something to the migration tool easy enough?

@zth If you want the whole story, I first added the tests and tried to make it work using the existing replace.type, then when I saw it didn't work and since the logic is not that complex, I first tried to do it by myself but you still need a pretty good mental model of the ParseTree (and I was not sure if I had to work specifically on exceptions or if it'd work with all variants), so I asked Codex, first pass did nothing so I guided it more, the second pass made the tests pass but was extremely verbose so I took a few minutes simplifying the implementation and here we are, I think the whole thing took maybe half an hour max, pretty straightforward I'd say!

I'll rename the annotation to replace.constructor!

[zth]

@tsnobip great, that process makes me glad! Hopefully means extending it is pretty easy for LLMs.