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
When loading an addon, the global window namespace is "polluted" with the addon name (e.g. the fit addon exports as window.fit). I know language purists balk at the idea of global namespace pollution but personally, as long as code works, I don't care. However, the addon export names are fairly generic (e.g. attach, fit, fullscreen, search). As a result, there's an increased likelihood that other code that also uses the global namespace could stomp on the exported addon before the Terminal.applyAddon() call is made (or vice versa - the addon could stomp on a global with the same name). If the exported names were prefixed or placed into an object named xtermAddons or something along those lines, it would reduce the chance of another piece of software declaring a global variable somewhere in their code with the same name as an addon here.
Standalone, this would be a breaking change. A possible route to take could be to add a namespaced export to the existing export, encourage users to move over to the new "no conflict" export mechanism via the docs/examples, and maybe remove the old export names sometime in the future.
The text was updated successfully, but these errors were encountered:
When loading an addon, the global window namespace is "polluted" with the addon name (e.g. the fit addon exports as
window.fit
). I know language purists balk at the idea of global namespace pollution but personally, as long as code works, I don't care. However, the addon export names are fairly generic (e.g. attach, fit, fullscreen, search). As a result, there's an increased likelihood that other code that also uses the global namespace could stomp on the exported addon before theTerminal.applyAddon()
call is made (or vice versa - the addon could stomp on a global with the same name). If the exported names were prefixed or placed into an object namedxtermAddons
or something along those lines, it would reduce the chance of another piece of software declaring a global variable somewhere in their code with the same name as an addon here.Standalone, this would be a breaking change. A possible route to take could be to add a namespaced export to the existing export, encourage users to move over to the new "no conflict" export mechanism via the docs/examples, and maybe remove the old export names sometime in the future.
The text was updated successfully, but these errors were encountered: