gjsify / ts-for-gir

TypeScript type definition generator for GObject introspection interfaces
https://gjsify.org/pages/projects
Apache License 2.0
233 stars 20 forks source link

flags should be GObject.ParamFlags in GObject.ParamSpec.object() #181

Open spazziale opened 1 month ago

spazziale commented 1 month ago

Using @girs/gobject-2.0: "^2.80.2-4.0.0-beta.9",

now the only type accepted is "string"

JumpLink commented 1 month ago

@spazziale sorry, my mistake. I hope this has been fixed. I release beta.10 now, can you test if it works again?

spazziale commented 1 month ago

seems to not be solved, maybe because i used

import GLib from '@girs/glib-2.0';
import GObject from '@girs/gobject-2.0';

due to #182

JumpLink commented 1 month ago

@spazziale are you generating the types by yourself or do you use the types published on npm? If you generates the types by yourself then there is now a bracking change: package.json support is now disabled by default. But you can enable it again with --packlage.

JumpLink commented 1 month ago

@spazziale Maybe you are simply missing a

import '@girs/gjs';
import '@girs/gjs/dom';

?

spazziale commented 1 month ago

@spazziale are you generating the types by yourself or do you use the types published on npm? If you generates the types by yourself then there is now a bracking change: package.json support is now disabled by default. But you can enable it again with --packlage.

no i'm using the ones from npm

spazziale commented 1 month ago
import '@girs/gjs';
import '@girs/gjs/dom';

nothing happen, here is my tsconfig.json that was working with beta.5

JumpLink commented 1 month ago

Can you try "moduleResolution": "NodeNext"?

spazziale commented 1 month ago

Can you try "moduleResolution": "NodeNext"?

using beta.11 import now works, should it be documented somewhere or it's something about my config ( still new to js/ts, sorry)? sadly the original error is still not fixed.

also i noticed that GObject constructor() doesn't take in input constructProperties

constructor(constructProperties = {}) {
        super(constructProperties); // Expected 0 arguments, but got 1.
    }

thanks for your work

JumpLink commented 1 month ago

yes, we should document it. I think it's because we use ESM + Node.js for package resolution and that's what NodeNext is for. “moduleResolution”: “bundler” should also work, but then a bundler like esbuild is needed as we do this in the examples.