TypeScript support
acrilex1 opened this issue · comments
Hello,
I am currently writing the TypeScript typings for this project. I can either publish them to DefinitelyTyped, include the typings here or simply update the package to be 100% TypeScript, as preferred.
Would you prefer that I create a PR for 100% TypeScript? I am modifying the code (adding signatures) anyway to generate the types correctly.
Would you prefer that I create a PR for 100% TypeScript?
No, thanks, but I would like to keep the project setup as simple as possible.
Regarding DefinitelyTyped vs inside the package: I have mixed feelings about both, up to you. I don't use TypeScript and the typings will most likely become outdated/wrong over time.
FYI: #25 contains a more up-to-date design of this lib, which is supposed to handle arbitrarily large GTFS datasets and contains a few fixed. It would be better to have typings for this (slightly changed) API.
Ok, in that case I can subscribe to this repo and keep track of type changes. The reason I asked for just having the project as TypeScript is because I have it done (easier than writing just typings), but I can just sync with your repo to generate the typings if you prefer.
FYI, the TypeScript part is currently in progress and will be in my fork in an hour, there is no functionnal code change, so up to you to decide if you keep with it or if I just export the typings...
No, thanks, but I would like to keep the project setup as simple as possible.
Was just asking because having the TypeScript version maintained would not be a big difference for you (it adds very little, if any, overhead), I don't quite understand how the setup would be harder, just a few dependencies more in NPM. Honestly the setup is done (contibutors just have to do a npm install), it would be alot simpler for everyone, especially those who use this lib, to have the typings when there are new releases. If there is a need for help with the TypeScript part, I'd rather stay available to help than to have to keep track of the repo, but in the end it is your decision.
FYI: #25 contains a more up-to-date design of this lib, which is supposed to handle arbitrarily large GTFS datasets and contains a few fixed. It would be better to have typings for this (slightly changed) API.
Perfect, I will go ahead and update my TypeScript fork for this part too.
Ok, in that case I can subscribe to this repo and keep track of type changes. The reason I asked for just having the project as TypeScript is because I have it done (easier than writing just typings), but I can just sync with your repo to generate the typings if you prefer.
I don't want to ignore your effort here! I'm just skeptic that TS will actually be worth its costs in this project, a rather small library with low complexity and a narrow scope.
No, thanks, but I would like to keep the project setup as simple as possible.
Was just asking because having the TypeScript version maintained would not be a big difference for you (it adds very little, if any, overhead), I don't quite understand how the setup would be harder, just a few dependencies more in NPM.
I disagree: a build step, editor integration, harder-to-read stack traces (without ts-node), etc. It adds up over time IMO. So far I've just seen too many projects and too much code that were more complex and more "indirect" because they were using TypeScript.
I disagree: a build step, editor integration, harder-to-read stack traces (without ts-node), etc. It adds up over time IMO. So far I've just seen too many projects and too much code that were more complex and more "indirect" because they were using TypeScript.
Agree to disagree, I will generate the typings and try to keep up to date. There is just the repo vs DefinitelyTypes question remaining. Both options are okay for me, in the end it is up to you. The advantage I would see to keep them here is that it would be easier to plan for new updates and include the typing changes when there is an API change.
Fine with me to have them in here, I will forget to update them anyways.
Remember to add the file to files in package.json.
I'm going to close this for now.
In case you still want to keep your fork up-to-date, I'm happy to refer to it in the readme of this repo!