Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds handling for typescript files to our Webpack config and converts App.js to get things started. It also includes some very basic stubs for AFRAME typing and our threejs modifications. We will continue to build out these stubs as we need them. Our custom BitECS JSX syntax is also supported and components are type checked (though most of the work for this is happening in another branch)
Actual conversion of ts -> js is handled by babel. Importantly this does not perform any typechecking. We do this since we still want our ts code to honor our browserslist targets and polyfills, and so that we can use HMR in the future. It also has the advantage of being faster. Typechecking is performed in parallel at dev time with ForkTsCheckerWebpackPlugin and at build time with
npm run check
, which actually callstsc
(the typescript compiler). It is configured not to actually emit any files, only check for issues.Since I was already testing things while adding typescript support to babel I went ahead and finally updated our usage of
@babel/polyfill
and audited the polyfills we were emitting. I blocked polyfills forArray.prototype.push
andArray.prototype.unshift
since they have existed basically forever and the polyfill (which we were applying in most cases) is only to handle a strange edgecasee that technically does not match the spec for arrays that for some reason have a readonly length. I also removed some unused transforms.Using typescript is opt in at a per file level, but the more of the codebase we convert the more we will see benefits (even in our non-js code). If you configure your editor to use the typescript-language-server you should start getting better type hints even in js files.
We should focus first on modules that will have the highest impact, namely anything providing functionality that many other modules depend on. I don't think we really have to strive for 100% code conversion, but it would be very nice if we could get nearly all the "engine" stuff converted. The React parts of the code are fairly low priority as PropTypes does an ok enough job providing some level of type checking.
For cases where you are not ready to convert an entire module but still want to add typing, JSDoc comments can bee used.