-
Notifications
You must be signed in to change notification settings - Fork 459
Initial TypeScript setup and conversion (CJS to ESM, ES5 class functions to ES6 classes) #707
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
Changes from 1 commit
5d43bc0
8107c3e
8f54529
89e6d20
dfdebf5
8aa8233
a4afeec
f011782
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,21 @@ | ||||||
| { | ||||||
| "compilerOptions": { | ||||||
| "rootDir": "./src", | ||||||
| "outDir": "./lib", | ||||||
| "target": "ES5", | ||||||
| "module": "CommonJS", | ||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (Switching to ESM at some point is going to be fun 🙄 )
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The |
||||||
| "types": [ | ||||||
| "node" | ||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I like this. On a selfish note, I think this will pollute our own code's types, because we run But from a less selfish perspective, this shouldn't apply to In an ideal world I think backend and client would be 2 separate packages in a monorepo, but that's obviously out of scope of this change.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This shouldn't affect any consumer code, since we compile to JS (plus eventually d.ts) and publish that. The TS compiler only cares about the main tsconfig you point it at. For any precompiled dependencies, it just reads the d.ts files. ShareDB client code already assumes access to Node libraries, necessitating a bundler:
The If we really wanted to do an internal split of tsconfig files, I think we'd want three - client, server, and shared - but even then, we'd still need to reference the Node types in client/shared code due to the two points above. To eliminate that, we'd have to rewrite the shared/client code to avoid Node built-in libraries or functions.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay this is fine for now, but I'd like to sense check when we eventually ship type definitions that I think the DefinitelyTyped types currently achieve it with things like this: import { Duplex } from "stream";Which I think has the "expected behaviour" of:
|
||||||
| ], | ||||||
| "strict": true, | ||||||
| "esModuleInterop": true, | ||||||
| "skipLibCheck": true, | ||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 😢 Why?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With this enabled, tsc will still type-check d.ts files that are directly or indirectly referenced by your project code, it just skips the default behavior of checking all d.ts files in node_modules. https://www.typescriptlang.org/tsconfig/#skipLibCheck I've just gotten used to using it in larger projects, where this can speed up compilation times by quite a bit, but we probably don't need it for ShareDB's relatively small dependency set. I'll remove it. |
||||||
| "forceConsistentCasingInFileNames": true, | ||||||
| "ignoreDeprecations": "6.0", | ||||||
| "noImplicitAny": false, | ||||||
| "noImplicitThis": false, | ||||||
| }, | ||||||
| "include": [ | ||||||
| "src/**/*.ts" | ||||||
| ], | ||||||
| } | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did you decide this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since a goal in this first phase is to keep the JS output compatible with the original JS code (prototype-based classes,
var, no for-of), ES5 was really the only choice. An ES6 compile target would mean the TS compiler outputsclasssyntax,const/letas in the source instead of converting tovar, etc.This can't be ES3 because our JS code uses ES5-specific standard library functions like
JSON.parse/stringify,Object.create(),.bind(). etc. Plus, TypeScript 5.5 removed support for ES3 output.So why not go with ES6 output since all remotely modern browsers support ES6 now?
There would be a less immediately obvious breaking change, where you can't use old-style prototypical inheritance to call a ES6 superclass. If you try to do
MyBaseClass.call(this)in the subclass constructor function, you'll get an errorTypeError: Class constructor MyBaseClass cannot be invoked without 'new'. A couple references:In practice what that means, is to upgrade to ES6 classes at runtime, you have to upgrade "leaf nodes" in the class tree to ES6 classes first, then upgrade their direct parents, and so forth up the class chain. (An ES6 class can call
super()to invoke a function/prototype base class just fine.)For ShareDB itself, we'd want to upgrade the leaf-node libraries like sharedb-mongo to ES6 class output first, then sharedb core. We'd also want to indicate in the major version release notes that consumers must either switch to ES6 class output themselves, or use a transpiler like Babel on sharedb code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool sounds sensible, just wanted it documented. Thanks!