Recently I tried porting a GJS app to TypeScript. Overall I found it a really positive experience. Strong type checking gives me much more confidence that the code I write will run before I run it, and I appreciate the tooling for in-editor error checking and other things that forced me to write more robust code. I think I would like to port Weather to TypeScript after this. However, there’s a big open question: are we okay with depending on the general web ecosystem for TypeScript in GNOME? Particularly, we’d need to depend on NPM.
NPM is a bit notorious for incidents like left-pad being pulled, or malicious code being inserted into popular packages or their dependencies. There’s also the issue of whether or not distros would accept packages that vendor dependencies for offline builds - some distros have been hesitant to include Rust projects for similar reasons.
I wanted to take the time to see what others think of these issues. I think using and promoting TypeScript as a part of the GNOME platform could be a huge boon for us.
From my perspective as one of the people looking at the platform as a whole, there are a couple of questions:
what does having TypeScript/NPM “in core” mean?
what are the requirements for using TypeScript?
The main advantage of using JavaScript as the embeddable language for our apps is that it does not have a standard library; this allows us to provide our own platform. What are the ramifications of opening up to NPM?
It is important to note that TypeScript is fairly platform independent. In order to get nodejs support, one usually depends on @types/node from NPM. I think the reason NPM is even being brought up is because TypeScript is distributed through NPM, so one would usually have a devDependency of typescript in their project’s package.json. And if TypeScript became more popular within GNOME, one would fetch @types/libsoup or whatever from NPM too, unless GNOME was hosting certain NPM packages.
npm is really only involved because that’s where the bindings are published
Given GitLab can already act as an ‘npm’ repository the dependency on the npm service itself can be avoided fairly easily I think, assuming @ewlsh is happy to move away from GitHub, though of course you’ll still need a client — be it npm, or yarn, or whatever is trendy this week.
For flatpak we already have scripts for vendoring such dependencies.
And of course all of these are only build deps, we’d still be running JS on GJS — it’d just be more type-safe and maybe minified than at present
yes and the type definitions can be used as git submodules similar to Rust bindings using gir/gir-files as a submodule. It just needs someone to keep it up to date with latest APIs.
There are 2 main types of dependencies that concern us with npm. dependencies which are expected to be used at runtime and devDependencies which are expected to be used for development/CI/build time.
TypeScript would be a devDependencies and we have a precedent for that in “core”. GJS uses npm to pin and install eslint.
The main advantage of using JavaScript as the embeddable language for our apps is that it does not have a standard library; this allows us to provide our own platform. What are the ramifications of opening up to NPM?
npm doesn’t provide a standard library and has not been specific to Node.js in a long time. Whilst it’s not popular, there are modules targeting gjs only on npm, for example gjspipe - npm
I recently wrote an app with GJS, and wondered if I should use Typescript or plain JavaScript.
I chose JavaScript + ESLint + JSDoc loaded with @gi-types, that doesn’t give strong typing but greatly helps with autocomplete. I didn’t choose Typescript not because of NPM (that I already use to pull the dev dependency), but because I feel JavaScript has become mature enough that the advanced features of TS don’t appear worth the trouble of setting up the compiler. However, having tasted Rust development, I can definitely see the appeal of strong type checking.
Regarding NPM, I only use it to pull the dev dependencies on the host (none of them are available on my distro), otherwise I use Meson and Flatpak to actually package the app.
I also have to say that, Typescript or JavaScript, the GJS bindings are a joy to use once you get used to the quirks of writing JS classes with GObjects.
Using a submodule is probably the cleanest approach:
create a separate repository—maybe under World/JavaScript, to allow non-core apps to contribute back
include all the type definitions generated from the current GNOME run time, separated by branch
include the TypeScript tooling and vendor in all its dependencies, with the option to update them easily from the repository
Then every application that wishes to use TS with GJS would need to add the repo as a submodule and include it as part of the build process.
The main issue is going to be downstream distributions packaging core GNOME applications written in TypeScript; vendoring isn’t really liked across the board. There are possible strategies, there:
vendor the submodule when generating the release tarball; this will blow up the size of the tarball a bit, but will avoid having to clone a whole submodule
distribute the generated JavaScript alongside the original TypeScript source when generating the release tarball
The main objection would be having to depend on additional tools at build time that may not be packaged downstream—and that will require downstream effort to package and track. I’d recommend getting distributions onboard for that well in advance.