Revamping extension dependencies #4241
Replies: 2 comments
-
This is very important to me. If we can build new extensions on top of existing ones, we can get more and more high-level extensions without rewriting or copying code every time. Like you said, there are several extensions currently using the copy/paste method. Thanks for these great ideas! |
Beta Was this translation helpful? Give feedback.
-
It would be very convienent to allow for extension dependencies and of course, it reduces copy-pasting, yes. At least the ability to inform, properly, a user of a extension dependency would be better than none at all. Thanks or taking the time to write the proposal! |
Beta Was this translation helpful? Give feedback.
-
We currently have an extension dependencies system:
It has a few issues that make it highly unpractical to use though:
I have a few suggestions to make that system more usable for everyone:
Add extension dependencies!
We are getting at a point where I see more and more extensions creators (including myself 😅) wanting to use functionality of other extensions, but either ending up on relying on copy pasting functions into our own extensions and privatizing them, which is not ideal for code duplication, for the developer experience, and for making functional experiences (since maybe that function relied on other functions/lifetime function from its original extension, that we as developers do not notice since we have that other extension locally, but will cause issues after being launched to users that did not install that extension).
Adding an extension dependency would replace the "Export name" field with a button to select the extension to depend on from the extension store. When installing the extension, GDevelop would notify the user that an additional extension is needed and download & install it before finishing the installation of the current extension.
Note: Find previous discussion on extensions dependencies here
Add JavaScript dependencies
JavaScript has an ecosystem of many interesting libraries. Unfortunately, they are quite difficult to access in GDevelop right now: We have to paste code into a JavaScript event, modify it if it puts the code in the local
this
instead of the global one, use a hack where you do} <the code> {
for PIXI plugins as they need to be initialized before the PIXI Renderer and therefore cannot wait for the first scene to be loaded before being called, lag the editor out because of the amount of code it is for monaco to tokenize....There is a better way! We could add javascript dependencies. The dependency "export name" could be either an NPM module, or a direct URL to the javascript library. It would be downloaded directly (when entering an npm module name, it could be downloaded via jsDelivr for example) and stored inside the extension, for offline use. A refresh button would allow to re-download it or another version any time from the dependencies screen. On export, this code would automatically be added as include to extension functions.
Add a GDevelop API to require modules
Currently, we need to do something like this to get access to an npm module:
Instead, we could have a simple and straightforward API like
gdjs.require
oreventsFunctionContext.getDependency
or something alike. It would simply import the module if it is present and return it.This would also make it easier in the future to remove the electron remote: the main use being importing modules, if we give a separate API that may use the preload electron feature to obtain a handle to the imported modules, we would pretty much not need it anymore, and get rid of this potential security issue.
This could also be made to work with javascript dependencies but that would be harder to achieve, I think that would only be useful for pure node modules (that are still important to have despite javascript dependencies, for all native node modules needs).
Beta Was this translation helpful? Give feedback.
All reactions