Typescript support
agyimr opened this issue · comments
We just had a major issue in production, causing some of our customers to not be able to access our application, due to a faulty segment tracking call, which failed due to the missing userId field. The blame is of course partially ours, since we should have implemented all the tracking in a fail-safe way, but I can't shake the feeling that should the package have correctly typed interfaces, we could not even commit faulty tracking code into the app.
We are using the @types/analytics-node package, in which all userId fields are optional.
Could you make sure that the interfaces reflect what you expect as tracking calls?
Hi @agyimr thanks for your report, we start looking into this
Typescript support is incredibly minimal. It would be really nice if we had types for things that are already well documented. Like traits and context for starters.
Is there a reason why the types are not included in the library by default? This has become commonplace for most modern libraries and even benefits Javascript code bases since most IDEs will still use type information for context tips/autocomplete. When the types and js code are in separate libraries it adds the hassle of ensuring that the type library version is for the same version of code in the Javascript library.
We're trying out Segment and having to switch clients from Amplitude to Segment and the developer experience in this space is much better from Amplitude.
The TypeScript definition in the DefinitelyTyped project is either currently (or originally) for analytics-node 3.1 which may have resulted in some of your issues @agyimr. Given that the project is already following JSDoc for documentation it might make sense to generate .d.ts files directly to avoid maintaining multiple sets of documentation.
More information on generation can be found here: https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html
@agyimr @yujidude @Jackman3005
Types are still a WIP (I am currently working on improving our current Context and Traits type FYI, see this PR), but if you or anyone in this issue is interested, I'd like to invite you guys to try out the analytics.js typescript SDK (BETA), written 100% in typescript. If you use the new SDK and have feedback, please leave it in the analytics-next repo, rather than this one.
@silesky thanks for getting back to us. Will take a look at the PR and the new TS library.
Is the new library where most of the energy is going for Segment? I've noticed some other issues getting lackluster response in this repo, hopefully the next iteration brings nice improvements.
Cheers,
Jack
@Jackman3005 Correct. As far as I'm aware, no new features are going to be added to this library (barring security vulnerabilities, etc), and it will be deprecated as soon as the new library goes into GA.
There are already significant improvements to the lib in the new SDK (mainly, graceful shutdown and the fixing of long-standing bugs), and, while it hasn't had an official release, I would recommend using our beta over this library today.
I am sorry you had to deal with poor responsiveness in this repo -- for historical reasons, this library was not build or managed 'in-house'. I think you'll find much better responsiveness once all activity / issues are confined to the analytics-next monorepo, as our full-time team is generally quite quick when it comes to triaging issues, especially when it comes to critical behavior.