Bricks version: 2.4-beta
Symptom: In the builder, clicking “Select file” / “Select image” on any control that opens the WordPress media modal (SVG element, Image element, etc.) does nothing. Console shows:
TypeError: this.activateMode is not a function
at media-views.min.js?ver=7.0.1:2:59731
at Lt (control-code.js:9:4794)
at $n.bs (control-code.js:9:40130)
at n._createModes (media-views.min.js?ver=7.0.1:2:59691)
Root cause: The split builder chunk assets/js/main.min/control-code.js (the new code editor) bundles lodash compiled with a UMD tail. The minified chunk contains mt._=yn, — i.e. root._ = lodash — which overwrites the global _ (Underscore.js) in the builder main window once the chunk loads.
WordPress core’s media modal (media-views / Backbone) relies on Underscore semantics: _createModes calls _.each(this.options.mode, this.activateMode, this) with a third context argument. lodash’s _.each (v4+) ignores the context argument, so this is lost inside the callback and every media frame construction throws — the modal never opens. The Lt frame in the stack is lodash’s internal arrayEach(array, iteratee) (2 args, no context), interleaved into media-views frames, which confirms window._ is lodash at that point.
Fix suggestion: Build the lodash dependency of the code-editor chunk as a scoped module (no UMD global export), or call _.noConflict() after the chunk loads. The chunk itself consumes lodash through webpack module references, so it doesn’t need the window._ global at all.
Workaround we’re using: an inline script after the underscore handle (builder main window only) that pins window._ via an Object.defineProperty setter trap — lodash (detected by forEachRight) gets stored to window.lodash instead, Underscore stays intact. Confirmed working.
