You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello and thank you for making your work Open Source.
I'm interested in contributing a TypeScript implementation of your reallysimple package and I am not sure what the best way to proceed is.
I run Deno 2.2. rather than NodeJS. My recent projects that work server and browser side are TypeScript based. I did some exploratory programming yesterday with Mistral LLM and it looks like it will be an easy port (TypeScript being a superset of JavaScript). If I complete the port would you be interested in a pull request?
I think the best way to approach it is to fork the repo into your space, produce what you want from it, and when it appears to work let me know and i'll point to it.
This has been an interesting experiment. I wound up forking several of the scripting modules. I'm working my way through porting them to TypeScript as well. The LLM I'm using, Mistal, has done a good job of porting from JavaScript to TypeScript. My experience is comparable to what you've described in on Scripting blog with chat-GPT.
After the initial prompts to port the code I've consistently used two additional prompts.
replace using the "request" module with the "fetch" command
Switch from callbacks to Promises using the "async" on functions and "await" for the variables receiving results
I find this update makes the code more readable for me. Not really sure if it makes a difference in performance.
Initially thought the challenges would be around porting the code. I've actually found challenges are more focused on the development environment. I want to avoid changing the packages.json or the original JavaScript. I know these packages are deeply integrated into your other projects so change either is likely to cause breakage.
Deno has a large degree of compatibility with NPM. There are some edge cases that crop up. I've found most of them have been solved by taking advantage of ES6 module imports relative path feature. I place the Scripting packages in adjacent folders. As a get a clean TypeScript version I re-point to the TypeScript implementation instead of your original JavaScript implementation. When I get far enough along to do a pull request we'll see if I'm correct in my approach.
Still plugging away at this. I haven't found a good way to take advantage of the newer features of TypeScript/JavaScript without creating breaking changes in the JavaScript original. This weekend that has lead me to think about the importance of naming things.
Is "github.com/rsdoiel/reallysimple" misleading?
Should it be really called something like "github.com/rsdoiel/ts_reallysimple"?
My fork has taken on the feel of a "port" rather than a minor tweak on the original. I feel like I am reaching a point where the TypeScript result is beginning to feel idiomatic. At the same time making it idiomatic is the primary reason for the breaking changes.
My effort is feeling a little like I'm remodeling a house. I'm adding windows and doors, changing the layout. I'm connecting the house to the garage by a hallway. The result is still the same building but it also not the original. Is this a "good thing"? Not really sure yet. Probably have to live in it a while to know.
It's been inspiring and fun to work with your code. Your continued reporting about how you use an LLM has been extremely helpful to me too. Thank you for listening (reading). Thank you for the advice and conversation.
Activity
scripting commentedon Apr 6, 2025
I think the best way to approach it is to fork the repo into your space, produce what you want from it, and when it appears to work let me know and i'll point to it.
rsdoiel commentedon Apr 12, 2025
This has been an interesting experiment. I wound up forking several of the scripting modules. I'm working my way through porting them to TypeScript as well. The LLM I'm using, Mistal, has done a good job of porting from JavaScript to TypeScript. My experience is comparable to what you've described in on Scripting blog with chat-GPT.
After the initial prompts to port the code I've consistently used two additional prompts.
I find this update makes the code more readable for me. Not really sure if it makes a difference in performance.
Initially thought the challenges would be around porting the code. I've actually found challenges are more focused on the development environment. I want to avoid changing the packages.json or the original JavaScript. I know these packages are deeply integrated into your other projects so change either is likely to cause breakage.
Deno has a large degree of compatibility with NPM. There are some edge cases that crop up. I've found most of them have been solved by taking advantage of ES6 module imports relative path feature. I place the Scripting packages in adjacent folders. As a get a clean TypeScript version I re-point to the TypeScript implementation instead of your original JavaScript implementation. When I get far enough along to do a pull request we'll see if I'm correct in my approach.
All the best, Robert
rsdoiel commentedon May 4, 2025
Good afternoon,
Still plugging away at this. I haven't found a good way to take advantage of the newer features of TypeScript/JavaScript without creating breaking changes in the JavaScript original. This weekend that has lead me to think about the importance of naming things.
My fork has taken on the feel of a "port" rather than a minor tweak on the original. I feel like I am reaching a point where the TypeScript result is beginning to feel idiomatic. At the same time making it idiomatic is the primary reason for the breaking changes.
My effort is feeling a little like I'm remodeling a house. I'm adding windows and doors, changing the layout. I'm connecting the house to the garage by a hallway. The result is still the same building but it also not the original. Is this a "good thing"? Not really sure yet. Probably have to live in it a while to know.
It's been inspiring and fun to work with your code. Your continued reporting about how you use an LLM has been extremely helpful to me too. Thank you for listening (reading). Thank you for the advice and conversation.
All the best,
Robert