Forum Academy Marketplace Showcase Pricing Features

Error ‘$jscomp is not defined’ When Publishing Plugin

Was this ever reported to Bubble as a bug (paging @neerja :slight_smile: )? I see a similar problem in a plugin that I am building.

I have a function defined as async (like "node.onclick = async function datePick(){ ") which works fine in my testing app, but does not work in apps that I’ve given Private access to.

One key difference (as you note) between testing mode and published mode is minification / compilation. When run in published mode, my plugin throws:

Uncaught ReferenceError: $jscomp is not defined
    at HTMLDivElement.d.onclick (eval at b.create_code (x5:17), <anonymous>:19:179)

Of course, in production mode I want my plugin to be minified, etc.

The problem area per the error message is:

d.onclick=function(){var b=this,e,d,f,g,h,k,l,p,n;return $jscomp.asyncExecutePromiseGeneratorProgram(function(c){if(1==c.nextAddress){;console.log("We are in datePick: clickDate is...",e,b.value,typeof b.value,e,typeof e);if(b.disabled||!|| c.jumpTo(2);console.log("WE ARE IN RANGEPICK START"); … etc.

So it looks like this compile/minify error (in my case) has something to do with the async nature of the function. (And this function must be called as async as it does some Promise handling and awaits resolution of a Promise within it.)

(And, after testing your solution @funwtp, I find that the published plugin does work. I don’t like that it’s in non-minified mode, however!)

1 Like

@keith For the ‘$jscomp is not defined’ error due to minification, here is the fix:

  • Open plugin editor
  • In console, enter window.do_not_minify_plugin = true
  • Publish plugin again
  • Test published version

If your issue is different, please submit a bug report.

1 Like

Hi @neerja, my issue is that. However, I should want this plugin published as minified. Your fix does in fact work for this, but isn’t this a bug that should be fixed on Bubble’s side?

The specific trigger for this bug is described above (presence of an async function definition).

REMOVING async (and then commenting out the “await” which of course will throw an error if used inside of a non-async function) and then re-publishing the plugin as do_not_minify_plugin = false , results in a minified version of the plugin that DOESN’T exhibit this error.

(Of course, the plugin does not function properly as certain features are dependent upon this async/await operation. But my point is that – at least in my case – the minification failure is quite clearly due to the async function definition.)

Wouldn’t this be a bug in the plugin builder that should be fixed on Bubble’s side?

There may be other things that trigger such failures, but I’ve identified this one very clearly.

1 Like


This plugin allows to specify size in px when you insert video.


PS adding a function to resize dynamically (like an image) is hard, but we are woking on it.

1 Like

Hi Neerja - thank you for this tip. I am having the same issue with a private plugin that works on the developer’s account but not on mine. I get the error: ReferenceError: $jscomp is not defined . Sorry to ask a potentially dumb question but since I have access to the Github version of the Plugin I’m trying to recreate it and troubleshoot.

Question: Where and what is the “console” that you refer to in step 2

  • In console, enter window.do_not_minify_plugin = true

I have searched though the Plugin interface and cannot work out what or where that is.

I may have found the answer to my question. The browser developer Console? i.e.

1 Like


1 Like

Thank you. Changing the header to the non-minified version of the required library code and using window.do_not_minify_plugin = true solved my issue. Odd though - seems like a bug.

Well, it is. (A bug.)

Let us know,what is bubble choking on?

Plugin dev here. It was throwing the exception referencing this line:

const yx = Array.from(Array(MAX_SERIES).keys()).map(i => {
    const yi = props['y'+i];
	if (!!yi) {
        return yi.get(0, yi.length());
    } else {
        return null;

Those steps seem to have done the trick, though. Working on both accounts.

Am getting the same error in Live, despite the plugin working in test.

It is also using async.

Hey @NigelG, in your test app, your plugin code is run in non-auto minimized form.

You can only tell if minification failed by testing the live version.

So, before publishing, turn it off. Then your live plug will not throw that error.

Now, you probably want your code minified anyway. You can use something like closure or uglify to minify and drop in your minified code.

(Because of this issue, I write my plugin code entirely in function initialize and then code actions become one-liners. You can see an example of this in List Shifter.)

1 Like

Ah, I guess that makes sense.

Doing the console command sorts it all out.

Turns out this still hasn’t been fixed. Once you come across this solution, all is fine and dandy, but oh boy did it take some time to debug up to this point…

1 Like

@emmanuel @josh



1 Like

@emmanuel @josh



Hello! As mentioned earlier in the thread, we added a workaround to bypass minification to avoid this issue when you create a new version, have you tried it?

You should type

window.do_not_minify_plugin = true

in the console in the plugin editor before creating a new version.

Can you give this a go?


Thank you very much for letting me know of the workaround described 15 months ago.

So, while I understand your aggravation, the issue here is that Bubble minifies your plugin’s code using Google’s closure compiler, but doesn’t offer us any way to set various options for closure compiler (which is a pretty complex bit of software).

Additionally, it’s not clear what version of closure compiler is in use.

So, if your code – for whatever reason – causes closure compiler to choke, you’ll wind up with this $jscomp is not defined error when you run your plugin. (The presence of this error means that closure compiler failed to compile/minify your code.)

And we don’t know what exactly caused closure to choke (because we don’t see its output), so all we can do is guess as to what the issue might be. Further, we can’t call closure with some different options set or whatever – we just have to accept Bubble’s defaults.

So: Your only fix is to tell Bubble not to compile your code. You do this by setting window.do_not_minify_plugin to true via the console while you’re in the plugin builder.

Now, of course, this is stupid because you probably do want your code minified. But of course you can do that yourself.

I have exactly the above situation with my List Shifter and Calendar Grid Pro plugins. (The issue in both of those cases is with my use of async / await in those. There’s nothing fancy, but there’s some flag that needs to be set for closure, OR the version of closure that Bubble uses is bugged. [I actually think the source of the problem is the latter – there’s specifically an issue with certain versions of closure and async/await that is fixed in later versions.]

And while it would be nice if those plugs could compile using closure, I’ve actually gotten used to minifying them myself with uglify (I generally just do it online using: and since I do it myself, I have control over what, exactly, happens during minification/optimization.

That’s useful because in addition to List Shifter not compiling due to async/await, there are certain variables that I need to keep the names of, even after minification or else a couple of important List Shifter features will not work (mostly the eval(x) operator in PROCESS List and the “debug” feature of PROCESS List)… And, of course, there’s no way for me to tell Bubble’s closure module that these variables are “reserved words” and must not be minified/changed/mangled.

For more on this type of thing and how I manage complex plugin development in Bubble, see my video here: Live Bubbling with @keith: Managing Complex Bubble Plugin Development, How Plugin Element/Action IDs Work (and How to Change Them), GitHub Sync and File System Case Sensitivity

1 Like

Hey, we’ve been keeping eyes on this for a while and have made some changes that should address the bug that was first mentioned in this thread:

  • Like @keith said very aptly, we compile all plugin code before publishing it through the Closure Compiler (which you can test out the behavior here)
  • This compiler is responsible for a few nice-to-have features which we think are best as default measures: it minifies the user-written code, strips out comments, and transpiles down to ES5-compatible code, for better browser-compatibility.
  • one of the ways that Closure compiles ES6 global functions into ES5 (like Array.prototype.values, or class) is that it creates its own global object called $jscomp before the function declaration and adds all the necessary polyfills in.

At the same time, there are safety implications to the way that we execute code, we strip out any code before the function declaration, and this unfortunately includes the polyfill functions. Because of this, if your code needed polyfills to run in an ES5 environment, then it would break because of the lack of said polyfills at runtime.

This was quite ugly, and for a while the only workaround was to either disable Closure compilation entirely (by adding window.do_not_minify_plugin = true in the plugin editor browser console before publishing) or to ensure that no ES6 functions would be polyfilled.

We have just pushed a fix that disables compilation automatically if Closure Compiler returns polyfills, so no action should be needed on your end, and no unexpected errors should happen at runtime anymore.

However, do note that this creates a slightly unpredictable compilation environment, which compiles and minifies code if no polyfills are needed, but doesn’t if polyfills are needed. Therefore, our recommendation is to still write code that should be ES5-compatible if you want to preserve browser compatibility, or to use a third-party minifier like Keith said, if you want browser polyfills to be declared inside your function.

Thank you for your patience,