Closed 12wrigja closed 3 years ago
For what it's worth, I do want to land this, but I don't think it's worth issuing a patch release for it as the end-user code is unlikely to change significantly. Thoguhts?
I see what you're saying. OTOH, version numbers are free, so I wouldn't mind cutting a release (especially now that the process is almost entirely automated).
The result is that any consumer of the .d.ts
needs to have TS4.4. Not sure if this is a problem, but would be at our code base.
Edit: Is this true? You have a hand crafted (or at least this is not updated automatically) jsbi/jsbi.d.ts in the repo (is this a good or bad thing?).
It's certainly true that it's hand-crafted - the typings existed before JSBI was migrated to TS sources. I did attempt to have this file automatically generated from the sources, but there were enough differences between the hand-written one and the autogenerated one that I didn't want to complicate migrating the sources over.
What build system is your codebase using? Does it use the sources directly, or the .d.ts in combination with one of the build artifacts from npm?
Sorry. This was not clear. We are not using JSBI. But we have customers which are consumers of our .d.ts files which are using ts3.9.x
So perhaps there are JSBI users which are using an older ts version, too.
I don't think currently the version of typescript that any JSBI users use matters given that the .d.ts file doesn't contain override. To be sure, I installed a version of ts 3.9.4 and compiled an example project I had against JSBI 3.2.5 and all seems well.
If we did swap to using generated .d.ts files, then maybe it would become an issue, but I don't think there's any plans for that to happen in the near future.
For what it's worth, I do want to land this, but I don't think it's worth issuing a patch release for it as the end-user code is unlikely to change significantly. Thoguhts?