[Request] externs.js for plugins

0 favourites
  • 9 posts
From the Asset Store
The I18N (Translation) is a Construct plugin created to translate text in game.
  • One of the things that most often go wrong is that the Closure Compiler trashes your code at export with minify.

    After this hard lesson you start writing everything with literals like MyExternalLib["activateAFunctionButMisplelled"] and it still will not work, but you don't notice that and spent some quality time debugging.

    But there is a solution that is already used for C2 standard plugins and that is to use a externs.js file. So this is something I would like for 3pp plugins as well.

    With that I can fully use both code completion and JSHint/JSLint type syntax checkers. If you are doing a large and complex plugin that is really an advantage.

    I have gone from using Notepad++ to Brackets and now WebStorm and finally it's easy to write javascript again. WebStorm will index C2s all system files and give you code completion for everything. Well almost everything, the edittime.js needs special handling so I did a "library" for that here: https://www.frostyelk.se/development/edittimeLib.zip

  • I forgot to make the request to Ashley, he is of course the only one to make improvements in this area

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I find the choice to force advanced optimizations as the only minify option is a poor one. It makes using a plugin with external libraries and minify pretty much impossible / a huge pain. It'd be nice to have a less vicious minify option.

  • You don't really need an externs.js file. Just use obj["prop"] syntax for anything from external scripts.

    Note if you use something like externalLib["someFunc"], then 'externalLib' is not using the ["prop"] syntax so will be renamed and broken by the minifier. Solution: just use window["externalLib"]["someFunc"].

  • Sorry Ashley for being unclear and jumping to solutions before making the requirements clear. What I want has nothing to do with extern.js but I saw it as a possible solution to my needs.

    What I want is:

    * Code completion in Webstorm when using external libraries in a plugin.

    As code completion is built on "dot" syntax it doesn't work when using literals. Another thing is that JSLint/JSHint complains about this, minor issue but I couldn't get Bracket to work after their last update.

    Any suggestions?

  • Aren't those feature requests for the tools you're using?

  • Arne

    You might place these could outside of runtime.js, so that they will not be minify.

  • I want the code to be minified but I want to use "dot"-code completion also. Now I have code that looks like this:

    var queryClass = Parse["Object"]["extend"](qClass);
    queryObject = new Parse["Query"](queryClass);
    [/code:39a6ce09]
    It looks horrible,  fails JSHint/JSLint, is error prone, does not support code completion or JSDoc type documentation. Just plain bad!
    
    To test how good it can be, I did my own [url=https://www.frostyelk.se/development/edittimeLib.zip]edittime.js lib[/url] with documentation and code completion support and get this when I point to AddCondition i WebStorm:
    [img="https://www.frostyelk.se/development/AddCondDocsLibWS.PNG"]
  • The c2 sdk is pretty limited, id imagine stuff like this would be part of c3. There are a lot of choices in the c2 plugin system that could be vastly improved. Obe major issue is plugins cant share a common ACE, so you end up having to do nasty workarounds. Theres a lot of features i wish the sdk had that would make advanced plugins easier to maintain. I feel the current sdk was designed with the expectation that the plugins wouldnt become very elaborate, or try to augment c2 in a meaningful way, and thus only needed the bare minimum in terms of inheritance and eddittime data management.

    As things stand its impossible to make plugins that require preprocessing without nasty hacks and workarounds. Another issue is that the edittime only has access to textures, so if you need to import some proprietary format, or some kind of file and display that data in the editor you just wont be able to. The data interface is severely lacking aswell, and doesnt allow any kind of interaction. Theres a lot of issues that c3 should address like this. I love construct but i feel the closed off edittime like this is a huge detriment to its growth.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)