What if we moved to TypeScript + a build step that strips types and maintains the character positions and line numbers of the authored code?
What problem does this feature solve?
Back when we built this library we made a decision to use JavaScript, largely to avoid a build step and know that what we write is what runs on our servers. However:
The difference now is that we can do this without requiring source maps or having the compiled code be radically different from the code we author.
Ideal solution
We switch to build our package source from TypeScript via type stripping a standard build process. Some requirements:
- We generate definition (
.d.ts) files instead of managing them manually
- We generate and publish source map files alongside the built code
This would involve a rewrite of our code and adding a build step before publishing. We'd also need to update documentation etc. This can be done without a breaking change however I think it'll be a lot easier if we do it alongside #1479.
What if we moved to TypeScript + a build step that strips types and maintains the character positions and line numbers of the authored code?
What problem does this feature solve?
Back when we built this library we made a decision to use JavaScript, largely to avoid a build step and know that what we write is what runs on our servers. However:
TypeScript-as-JSDoc isn't very well known amongst our engineers
We currently maintain manual
.d.tsfiles which is an overhead that could be removedThe difference now is that we can do this without requiring source maps or having the compiled code be radically different from the code we author.
Ideal solution
We switch to build our package source from TypeScript via
type strippinga standard build process. Some requirements:.d.ts) files instead of managing them manuallyThis would involve a rewrite of our code and adding a build step before publishing. We'd also need to update documentation etc. This can be done without a breaking change however I think it'll be a lot easier if we do it alongside #1479.