Improve type-checking inside the engine source code #3358
Replies: 3 comments 1 reply
-
Does this mean we add a bunch of typedefs to a lot of the files? Does this affect JS docs in any way? Should we include all types that are needed anyway? Not just the minimum to build the engine? |
Beta Was this translation helpful? Give feedback.
-
It would be also great to find a way we can have all typefeds in a single file for the project, that gets included using a single line into any source files. Perhaps something like this: |
Beta Was this translation helpful? Give feedback.
-
TypeScript is analyzing code dependencies and removes dispensable (type) imports, so technically you probably just need to put I did a little test for just this one file example of yours: I added this line: import { GraphicsDevice } from 'src/graphics/graphics-device.js'; And type definitions where TS/VSCode expects them (differs from strange JSDoc style over the class itself): class ForwardRenderer {
/**
* @type {GraphicsDevice}
*/
device;
/**
*
* @param {GraphicsDevice} graphicsDevice
*/
constructor(graphicsDevice) {
this.device = graphicsDevice;
var device = this.device; And then just compile it for comparison: |
Beta Was this translation helpful? Give feedback.
-
In the engine source code, we only import modules that are required in order to build the engine. This leaves many types unknown to Visual Studio Code (or similar JS editor), and we see the type with red underscore, and when typing
this.device.
we don't get any code-completion aids. This is what we see:We could adopt the use of typescript typedef imports to improve the situation. First, we'd need to import the type this way:
Then declare this.device to be of type GraphicsDevice
And then Visual Studio gives us code-completion and understands and validates the function signatures.
(Thanks to @vkalpias who's started to use it in Editor API he's working on)
Beta Was this translation helpful? Give feedback.
All reactions