Third-party addon changes to support JavaScript Modules

1 favourites
From the Asset Store
Helping streamers give their viewers more excitement.
  • As of r226, Construct 3 supports JavaScript Modules, which brings significant improvements to the scripting feature. It also improves the loading time of preview, as it works around a Chrome bug that causes slow loading times in the old "classic" mode.

    For technical reasons, the entire runtime and all third-party scripts all have to run in the same mode - either classic or modules mode. I would imagine most third-party addons do not need to make any change to support modules mode. However an issue came up with one third-party addon that suggests some addon developers will need to make changes. The necessary changes should be very small and quick to make, at the same level as routine bug fixes or maintenance that all responsible addon developers should already be doing. Also if addons are broken in modules mode, they are probably broken in other cases, such as after export, or when minifying, so these changes ought to have been made anyway regardless of the introduction of modules mode.

    The Addon SDK downloads have all always used strict mode and per-file scopes, so are not affected by the following changes. It is only cases where external scripts have been brought in, or if addon developers have altered the SDK files to remove their strict mode or file scope.

    JavaScript Modules - and Closure Compiler, which Construct uses for minifying code - are both used widely in the industry outside of Construct. So these changes are not specific to Construct: they are also necessary for compatibility with the wider JavaScript ecosystem.

    For users

    If you are using a third-party addon that is broken in modules mode, you can temporarily work around the problem by changing the Scripts type property (in the Advanced section of Project Properties) back to Classic. However this option is deprecated and will be removed in a few months, so you should contact the addon developer and ask them to make a small, quick update according to the information below.

    Strict mode

    JavaScript introduced a new strict mode in around 2011. This avoids common mistakes. See Strict mode on the MDN for more details. The old non-strict mode is called "sloppy" mode and is not recommended.

    Modules mode runs all scripts in strict mode. If a third-party addon developer wrote code relying on features specific to sloppy mode and still had not updated it to use strict mode, it will now need to be updated.

    One example of this is assigning to undeclared global variables is allowed to create a global variable in sloppy mode, but is an error in strict mode (to help catch accidental typos). For example:

    // Assuming 'newVariable' is not declared anywhere else, this is 
    // allowed in sloppy mode, but throws an error in strict mode 
    newVariable = 10; 
    

    If the intent is to create a new global variable, explicitly add a property on the global object instead:

    // Always works 
    globalThis.newVariable = 10; 
    

    Note: if addon developers have updated their code to work with the new script minifier - a change we announced several months ago in July 2020 - this type of usage should have already been corrected.

    Module scope

    In classic mode, variables declared at the top-level scope are available globally. In modules mode, variables declared at the top-level scope are only available within that module. For example:

    // Classic mode: declares a global variable 
    // Module mode: only scoped to this module 
    let myGlobal = {}; 
    

    Once again, the fix to this is to explicitly add properties on the global object:

    // Works in both modes 
    globalThis.myGlobal = {}; 
    

    Once again, this specific type of change is something that should already have been made since we switched to the new script minifier back in July, since Closure Compiler only supports the latter syntax.

    Summary

    In many cases nothing will need to be changed at all. In most other cases there will only need to be one or two lines of code changed.

    For example one addon attempts to declare its namespace via a sloppy mode global assignment, i.e. MyNamespace = {}. Once changed to a proper global property it should work again. The global property can also be declared as a local variable to avoid having to rewrite any more code, e.g.:

    // Make local variable for this script 
    const MyNamespace = {}; 
     
    // Also set as global variable for external calls 
    globalThis.MyNamespace = MyNamespace; 
     
    // Rest of script probably needs no further changes 
    

    Classic mode will be removed in a few months (likely by March 2021), so addon developers should make any necessary tweaks by then.

  • Thanks for the tips Ashley, I am using some 3rd party external js in the Spine C3 addon (specifically the 'spine-ts' js library/distribution) and it does the 'sloppy' global declaration for the spine library. For now I changed the definition to globalThis.spine, instead of a top level 'spine' and it is now working again.

    I'll look to update this and the rest of the addon to 'modules' in the future.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I realized that if I go ahead and use module import/export, my addon will not be backward compatible to pre R226, so I'm going to continue to use the globalThis method for now, until the module mode goes into the stable branch.

  • For users

    If you are using a third-party addon that is broken in modules mode, you can temporarily work around the problem by changing the Scripts type property (in the Advanced section of Project Properties) back to Classic. However this option is deprecated and will be removed in a few months, so you should contact the addon developer and ask them to make a small, quick update according to the information below.

    Maybe I misunderstood this. I cannot find this setting (in the Advanced section of Project Properties), not in existing projects or in new ones. So for me I cannot use 226 or 227. Still only 225.

  • Oops, that property was accidentally hidden. It should be back in the next beta.

  • Thanks, now it works fine in 227.2

  • Oops, that property was accidentally hidden. It should be back in the next beta.

    Ashley, is there a way to figure wich addons need to be updated in a project ?

    i use quite a few, cant tell witch one or ones might be the problem, so i cant switch to modules.

  • Try using each addon one at a time in a new project.

  • Try using each addon one at a time in a new project.

    aye , did just that.

    seems to be all of them ? D:

    on update 228 it crashes on preview

    on update 229 it freezes on loading preview

  • You'll need to contact the addon developers to get them to make a couple of minor changes as described above.

  • Hi! I hate being that pain in the neck guy who criticizes everythings but... Couldn't you like send like a dedicated email like about exactly that? So I could update my plugins 3 months ago? I mean I have an account here and there's a ton of plugins published by my account. Which kinda means I'm a plugin developer.

    Probably there's a reason to not have done that which isn't obvious to me. And if so, I apologize.

  • Hi,

    Is this why games with "rex move to" and "litetween" plugins is not working anymore?

    Regards

    Shubham

  • Hi,

    Is this why games with "rex move to" and "litetween" plugins is not working anymore?

    Regards

    Shubham

    Litetween don't work with Module, only with Classic.

    Also doesn't work with the "new" minification.

    So... when classic mode gets removed then a LOT of projects will brake totally

  • Hi! I hate being that pain in the neck guy who criticizes everythings but... Couldn't you like send like a dedicated email like about exactly that?

    We don't have an email list for all addon developers. We don't actually know who they are - addon developers work entirely independently to us. We also don't know whose addons are already compatible and whose addons actually need an update, since as the post explains, lots of addons should keep on working fine, especially if you were already using strict mode that's been a part of JavaScript since 2011.

    This change has also been live in Construct since r226 in late November, so if you needed to update your addon, it should have become clear at that point.

  • We don't have an email list for all addon developers. We don't actually know who they are - addon developers work entirely independently to us.

    Let me help you with the list of addon developers. Here's a full list of C3 addon developers user id's that have their addons published in the Addons&Extensions section. You just need to retrieve their emails that they, inevitably, have, otherwise they wouldn't be able to publish an addon on construct.net.

    I believe these people deserved a tiny bit of your extra effort of targeted informing that there was a new feature that could potentially break their addons. Since it's not their job to read every release alert that you send out in plenty.

    292985 
    25994 
    613625 
    911331 
    871735 
    87262 
    16284 
    362473 
    124350 
    545049 
    408233 
    15836 
    122660 
    388181 
    429195 
    266762 
    198994 
    204184 
    604343 
    112879 
    822777 
    764487 
    222612 
    309204 
    413985 
    587960 
    65958 
    286738 
    156822 
    223559 
    49541 
    450214 
    367684 
    561566 
    16414 
    533686 
    522430 
    93430 
    202714 
    267702 
    88519 
    253158 
    16207 
    409473 
    18002 
    19572 
    73219 
    423944 
    39782 
    

    Next time you need someone do the most basic work, don't hesitate to ask for my help.

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