dcodeIO
dcodeIO
Removing the `good first issue` label here, because this might become quite tricky. Not super tricky, but potentially too tricky for a very first issue.
Isn't the issue rather the value in, say, `types.defaults["int64"]`? Already does a lookup there, whereas the new `isLongType` seems redundant on this basis.
The issue is patched since 6.11.4 respectively 7.2.5, as per [CVE-2023-36665](https://github.com/advisories/GHSA-h755-8qp9-cq85).
This is something we might consider in the future, but at the current state, that is without our own language server, reusing the .ts extension appears to be the best...
Last time I checked tsc hard coded the supported file extensions and the only way to change it was to maintain a fork. That was around the time of the...
Here's a little repo showing what GitHub would make of `.as`. Can also be forked to see what needs to be done to make everything work both on the TS...
Fwiw, I'm favoring `.as`, mostly for aesthetic reasons (`.js`, `.ts`, _A_ssembly_S_cript). Would like to have a language server to make proper use of it before making the switch, though.
PRs welcome, of course, though seems that ship has sailed.
@tlively We are, of course, accepting PRs. I also went ahead and addressed some of the typing changes that had accumulated since the last time I checked - modulo the...
I'd also be interested in a Wasm-only build, even if it's limited but otherwise works. With that the AS compiler (along Binaryen) could run on let's say WasmTime :)