You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we use the goog.provide and goog.require system for declaring dependencies in blocklyeditor. However, newer versions of Closure Compiler have support for ES6 modules when using a language_in of ECMASCRIPT_2015 or newer. We should transition the blocklyeditor code to using ES6 modules as it would give us more flexibility in the future, possibly to consider other packaging tools if needed.
The text was updated successfully, but these errors were encountered:
I agree with transitioning the blocklyeditor code to ES6 modules. The current use of goog.provide and goog.require is part of the older Closure Compiler module system, which has now been superseded by ES6 modules in modern JavaScript development. By moving to ES6 modules, we’ll be able to take advantage of a more flexible and widely-adopted standard. This will also open the door for using other bundlers or packaging tools in the future, which may offer better performance and more features.
In addition to the standardization benefits, ES6 modules offer improved tree-shaking and better interoperability with modern JavaScript ecosystems. This transition will position us well for future updates, making it easier to manage dependencies and integrate with new tools.
Currently we use the goog.provide and goog.require system for declaring dependencies in blocklyeditor. However, newer versions of Closure Compiler have support for ES6 modules when using a language_in of ECMASCRIPT_2015 or newer. We should transition the blocklyeditor code to using ES6 modules as it would give us more flexibility in the future, possibly to consider other packaging tools if needed.
The text was updated successfully, but these errors were encountered: