Modern TypeScript support for Gnome Shell extensions

The Issue

Recently I’ve been working on a library for GJS
that brings some DX improvements to the language: Decorators for GObject
subclassing and D-Bus interfaces and a JSX runtime for both Gtk and Gnome Shell.

As a proof of concept, I built an
extension with the library.
The issue is that since decorators are not part of the spec yet (stage 3) and
GJS does not support it, the code has to be transpiled. However, the transpiled
JavaScript is not very human-readable, and my submission to
extensions.gnome.org was rejected as a result.
Another reason for the rejection is that I used a bundler and submitted a single
JS file with around 10000 lines.

It is not possible to produce human-readable JavaScript with modern tools like
tsc, esbuild or swc, as they were never designed for that purpose.
Avoiding bundling the code is also kind of impossible or rather, it would
produce even less readable code, since the glue code to make modern syntax work
would have to be included in each module. On top of that, the build process
would become unnecessarily complex to handle npm packages and support a monorepo
setup, which is required to have the JSX work differently for preferences and
extensions.

In conclusion, it currently isn’t possible to use the library I built for Gnome
shell extensions, because it won’t pass the review, which makes sense, I would
not want to review a bundled JavaScript file either, but they have to be,
because the submitted zip file could be tempered with, and the source code alone
cannot be trusted, it would be a security risk.

Solution

I see two possible solutions:

  1. EGO should support TypeScript. Allow developers to submit the original source
    code and have EGO handle the transpile/bundle step. This way, reviewers can
    examine the actual source code instead of transpiled JavaScript, and the
    build process cannot be tampered with. I’m not sure how feasible this is,
    since each extension might use different build tools.

  2. Gnome Shell should support third-party repositories. This way the
    responsibility is placed upon the users to trust in developers instead of
    reviewers, but would still allow users to install extensions with a single
    click.

1 Like

I agree with the general sentiment here. TypeScript is a grand improvement for the developer experience and works with a any number of tools to provide an environment developers have come to expect.

I’d suggest one reason why TypeScript support (for GNOME Shell extensions) isn’t better, is simply that GNOME Shell is still written in JavaScript. Personally, I prefer to write smaller extensions that monkey-patch more in JavaScript because it’s easier to track those patches mentally. This is effectively what reviewers are doing, so accepting verbatim TypeScript with confidence is difficult.

I think, moving forward, it would be an excellent idea for us as a community to decide on an official toolchain for TypeScript transpilation (at least for extensions). Personally, I don’t have enough experience with that ecosystem to make strong recommendations, though.

This one is tougher, both because we distribute off GNOME Foundation infrastructure (licensing and liability may be an issue; IANAL), and because including external software that way basically makes the assurances of review moot.

The JS/TS ecosystem is fairly large, especially in terms of the possible packages people might pull in to get a project done. I’d suggest the only way to do this reliably would be something like @sophieherold’s rust-supply-chain, but that’s a lot of work we would need volunteers for.

Anyways, that’s my two-cents :slightly_smiling_face:

2 Likes

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.