-
Notifications
You must be signed in to change notification settings - Fork 445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Tracker] js-libp2p getting full Type Script support #1021
Comments
😍 |
Converts this module to typescript Track: libp2p/js-libp2p#1021 BREAKING CHANGE: No more default exports, no more CJS
Updates aegir and removes `tsconfig.json`. The types for this module are pretty broken, so remove the config temoprarily - this will be re-examined at a later date as part of libp2p/js-libp2p#1021
Updates aegir and removes `tsconfig.json`. The types for this module are pretty broken and are not generated from the source anyway, so remove the config temporarily - this will be fixed up at a later date as part of libp2p/js-libp2p#1021
Converts this module to typescript with ESM-only publishing. Part of the wider effor to move libp2p to the bright new future of proper types and ESM: libp2p/js-libp2p#1021
Converts this module to typescript with ESM-only publishing. Part of the wider effor to move libp2p to the bright new future of proper types and ESM: libp2p/js-libp2p#1021
Converts this module to typescript with ESM-only publishing. Part of the wider effor to move libp2p to the bright new future of proper types and ESM: libp2p/js-libp2p#1021
Converts this module to typescript with ESM-only publishing. Part of the wider effort to move libp2p to the bright new future of proper types and ESM: libp2p/js-libp2p#1021
Converts this module to typescript Track: libp2p/js-libp2p#1021 BREAKING CHANGE: No more default exports, no more CJS
Not sure what the current scope of this issue is, but would be nice to include lower level dependencies in this, too. This would also be an opportunity to tighten up the types (remove |
Another angle worth tackling that may be revisited with better typescript tooling: |
@wemeetagain yes to generated docs! Further discussion here - ipfs/js-ipfs#4021 |
@achingbrain : does this issue eclipse #659 ? |
@BigLep yes, that one can be closed |
This has shipped in |
A few years ago we took the decision on TypeScript to not convert modules to the language, because it's not a standard, it's controlled by a single vendor, it requires lots of extra tooling and there were far more JavaScript developers than TypeScript developers, and all TypeScript developers could write JavaScript but the reverse was not always true.
We were going to use JSDoc comments to generate types so people could use libp2p/ipfs modules in typed environments. TypeScript developers would get types, and JavaScript developers would get comments, everyone would be happy.
Fast forward a few years and what's changed? TypeScript has gone from strength to strength, that single-vendor has made some significant plays in open source with acquisitions of npm and GitHub so they're not going anywhere. Far more developers are writing TypeScript than before.
The JSDoc comment thing didn't work out - it's full of gotchas and introduces so much cruft to the codebase that it makes it unpalatable to both JavaScript developers and TypeScript developers - full TypeScript ends up being much less verbose. We tried writing complex types in
.d.ts
files but the tooling isn't there to validate them, so we've ended up writing.ts
anyway.Meanwhile JavaScript has moved on, as it did from callbacks to promises, now it's away from CJS and towards ESM.
We've been shipping most new code in dual CJS/ESM mode which has meant we've been able to support future-tech like skypack but also maintain compatibility with older tools that use the resolve module from browserify like jest, this is also full of footguns, for example
instanceof
not working between instantiated from CJS then used withinstanceof
in ESM.Many of our dependencies are now ESM only - since we bundle CJS and ESM we can't update to these as our CJS code would end up pulling in the ESM dependency via a
require
which isn't compatible.Fast forward to now. We're standing on the cusp of a CJS to ESM transition, so why not take the opportunity this presents to embrace the peace of mind TypeScript brings at the same time.
We will refactor existing libp2p modules from CJS to TypeScript which will be published as ESM only with export maps and all that good stuff. This will let us move quickly and safely while supporting new tools and environments.
Porting
A cheat sheet for porting existing modules. This will evolve over time as we move some of these steps into Aegir itself in order to reduce the amount of boilerplate required (testing/coding flow, I'm mostly looking at you).
PRs
Needed for examples:
The text was updated successfully, but these errors were encountered: