Usage without bundling?

[swsnr]

I'm trying to replace my hand-written GNOME Shell types with this repository, but no matter what combination of module and moduleResolution I try, I can't get these types to work.

Specifically, if I set module and moduleResolution to Node16 in tsconfig.json, I get errors like these from the type definitions on tsc --build tsconfig.json:

node_modules/@girs/gnome-shell/dist/misc/extensionUtils.d.ts:3:32 - error TS2835: Relative import paths need explicit file extensions in ECMAScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean '../extensions/extension.js'?

3 import type { Extension } from "../extensions/extension";

I can suppress these with "skipLibCheck": true, but it makes the type definitions unusable because none of the relative imports get resolved, so typescript is missing proper type info all around.

I don't really understand what I'm doing wrong, and the documentation is somewhat lacking. All examples (here, as well as in the gjsify/types repo) seem to use some sort of bundling, and there seem to be no instructions around just using the types for tsc without any kind of bundling.

---

Besides, I looked at the example to understand how it does things, and as far as I understand it uses esbuild to bundle all TS into a single JS file as you'd to for web. I looked at the generated JS and that's the convoluted unreadable mess you typically expect from a bundler.

I don't understand how this is supposed to work with extensions.gnome.org whose review guidelines explicitly request non-obfuscated code even after typescript compilation. In a review of my extension I was actually ask to add a prettification step as post-processing to make the code more readable, even though I just submitted the tsc output literally without any bundling.

So I can't image that a bundled extension file with output similar to what esbuild creates in the example would pass review on extensions.gnome.org. Did anyone actually ever submit a bundled extension?

Edit: A previous version of this text had an entirely unrelated error which was a result from messing around too much 🙈

[swsnr]

Okay, by looking at what gTile does I figured out that I can indeed just ignore these errors, and things still work.

I'm closing this issue, but I'll perhaps make a merge request which fixes these errors.

[schnz]

Hey @swsnr ,

I'll re-open this for now. I believe it should be fixed. The imports seem to be resolved correctly by VSCode but it would be nice if skipLibCheck could be set to false.

I think I will find some time tomorrow - also for your PR.

[swsnr]

No hurry 🙂

I've changed the affected imports in my PR, and at least for my extension lib check passes with those changes. So chances are that we can close this again after my PR is merged 😊