-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The buildType
option doesn't work yet.
#168
Comments
@vixalien Unfortunately, we have not yet updated the documentation on the main branch, but hopefully this will happen soon. The option is still available in the 3.x branch. On the main branch the option has been removed, why do you need this to replace gi.ts? |
We use gi.ts to generate typescript declaration files like the ones at https://gitlab.gnome.org/BrainBlasted/gi-typescript-definitions. These files are included as submodules in apps where we can't use npm to install the types like Decibels and GNOME Sound Recorder. I thought gi.js was being replaced by this so I thought this feature would be too much to miss. |
@vixalien I have removed the option because it should not absolutely necessary for your case and this simplifies the maintenance effort. You can still generate the types, with the difference that a separate folder is created for each generated type and a However, the package.json is practical because it makes it easier to import the types, as typescript can then resolve this more easily. For this you need to add the path of your generated types (e.g. {
"compilerOptions": {
"baseUrl": "../gi-typescript-definitions",
"types": ["gjs", "gio-2.0"],
"module": "ESNext",
"moduleResolution": "bundler"
}
}
Alternatively you can use a package manager like Then TypeScript should know the types for the imports like this (thanks to the ambient module definitions included in this types): import GLib from 'gi://GLib?version=2.0'; So no bundler is necessary to use the types in this way. However, a bundler can also be used if, for example, one is used anyway, in which case the types could also be imported in this way (but this is not necessarily): import GLib from '@girs/glib-2.0'; The So there should be several ways to use the self-generated types anyway. Or do you have such a special setup that this is not possible for you? Then please explain this to me in more detail, we are of course very interested in everyone being able to use the types. I haven't fully tested this without the package manager yet (but is tested using yarn workspaces), so problems are not excluded, if it doesn't work as I described, I would of course work on a solution 👍 Edit |
GJS doesn't use
This already worked with gi-typescript-definitions with the generated
When using GJS directly, there is no need for any All in all, the package.json and .js files tell me this is made for compatibility with node.js (presumably node-gtk). It also says in the README that support has been dropped for node-gtk, but we still have those files. I strongly suspect that not generating these files (or at least adding an option not to) will ease the development process. I have an example of an app where I use external: ["gi://*", "format", "gettext"], If you are using another bundler and the I would also like to know if any apps import the types using the |
@vixalien Thanks for the feedback, I have a few more questions about your use case: Do you write your sources in TypeScript? And if so, how do you transpile the sources to JavaScript? Do you use I know that GJS does not support package.json. In the suggestion I tried to explain, the package.json is not used at runtime but only in the previous process by For esbuild you just need to set the option |
I have now created a working example that shows how to generate the types by yourself and use them to create a simple GJS application with This example also uses the |
And here an almost identical example, but uses The example also uses the direct |
You can find more examples in the What I could also add would be support for a declaration file that contains all generated types, so that only one entry in tsconfig.json is necessary, if that would still help. By the way: For the future I plan to support JSR which is a TypeScript runtime independent package registry. So it is independent of Node.js and supports Deno, Bun, Node.js and any other JavaScript runtime environments, so I think it makes sense to publish packages for GJS there instead on npmjs.com. I understand, however, that the long-term goal should be to be able to completely do away with Node.js, and that is also my long-term goal. In the long term, I would like to run ts-for-gir itself with GJS instead of Node.js. But at the same time I think that it doesn't hurt to have a package format with metadata and we can just use the metadata format of the As far as I know, the GNOME Bundler is also working on TypeScript support. I still have to familiarise myself with this, but I am interested in how the types are handled there and to what extent we can work together here. Please don't get me wrong, if there really is a need for support without a package.json, I'll be happy to add it, but I'm not convinced yet. |
@vixalien Did my examples help you or do you think it would be better to read support without package.json? |
Hello. I didn't take much time to examine the situation so forgive me if my responses are a bit shallow, but it seems the issue is that the new direction of the project is trying to work with other JS runtimes (Node, Bun, Deno, etc...) while kind of forgetting GJS. I say this because of the addition of With the current approach, ts-for-gir doesn't work with GJS, so we are still using outdated gi.ts. It would be nice to atleast have the old behavior of gi.ts and then maybe improve it from down the road.
It's Workbench that's working on TypeScript support, and that actually requires projects like gi.ts and ts-for-gi, not the other way around.
Just so you know, this brings absolutely nothing to the table for GJS. GJS doesn't support package registries at all. Unless some work is done, jsr/node/cloudinary will almost mean nothing to GJS (unless you use BOTH Node and GJS, but that's another topic).
Yes. The package.json and all the additional files are really unused for GJS-based typescript solutions. All that's needed is that declaration file that links all generated types, like |
@vixalien Okay then I will try to implement it again to be independent of a |
In the CLI, there's supposed to be an option called
buildType
to change the output format to just generate a .d.ts file, however that doesn't seem to be implemented yet.Because of this, ts-for-gir can't really replace gi.ts right now
The text was updated successfully, but these errors were encountered: