xterm.js
xterm.js copied to clipboard
xtermjs
Loading via browser and the Universal Module Definition
In Issue #2499 it was asked why addons don't work when loaded by browser from a CDN.
Addons are supposed to work as so:
const t = new window.Terminal();
const a = new FitAddon();
t.loadAddon(a);
But the UMD returns an object, so it's necessary to do this:
const t = new window.Terminal();
const a = new FitAddon.FitAddon();
t.loadAddon(a);
Here's a full example:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/[email protected]/css/xterm.css" />
<script src="https://cdn.jsdelivr.net/npm/[email protected]/lib/xterm.js"></script>
<script src="https://cdn.jsdelivr.net/npm/[email protected]/lib/xterm-addon-fit.js"></script>
</head>
<body>
<div id="terminal"></div>
<script>
const t = new Terminal(),
f = new FitAddon.FitAddon();
t.loadAddon(f);
t.open(document.getElementById('terminal'));
t.write('Hello from \x1B[1;3;31mxterm.js\x1B[0m $ ')
</script>
</body>
</html>
The UMD conditions are:
if(typeof exports === 'object' && typeof module === 'object')
module.exports = factory();
else if(typeof define === 'function' && define.amd)
define([], factory);
else if(typeof exports === 'object')
exports["FitAddon"] = factory();
else
root["FitAddon"] = factory();
Perhaps the last line should be root["FitAddon"] = factory()["FitAddon"];.
@lachdoug See my warning in #2499 regarding CDNs. Pls lets not spread a bad habit.
This is not a CDN issue, per se. The issue is whether xterm addons should be loadable without a module system, using a <script type="application/javascript"> tag. There are times when it makes sense to load xterm this way. I teach a web dev class to high school kids. It's basic stuff. We use xterm in a lesson about character encoding. Loading libraries into global namespace (yes, from a CDN) is all the students know at this point. NPM and Webpack come later.
@lachdoug I know that this issue is not about CDN in the first place, still your snippet contains/shows that, and thats the reason why I called it out. Those snippets are often used as copy blueprints, even by long-standing web developers which should know better. Imho the only usecase, where loading xterm.js exact that way makes any sense, is an in-browser only REPL, that does not try to to talk to an outside shell.
Or from a teachers perspective - combining a slightly enhanced version of that snippet with aspects about web security with proper SRI usage, building a chain of trust etc. would at least give your kids the chance to understand the risk and enable them to decide on their own whether they go the secure or insecure way later on. Giving them this snippet without any security context is like handing a sharp knife to a child without telling about the handle and the blade - it will grab right into the blade.
Ofc its not up to me to tell you how to teach your kids, its just whats on my mind regarding xterm.js and insecure CDN usage.
These kids are 12 and 13. Some of them can't remember how to open their text editors. I'm not going to be talking with them about 'chains of trust'. We're just playing around with a bit of ASCII art. I'm sorry for mentioning CDNs and teaching. These are irrelevant and have distracted from the trust of the issue, which is: xterm's UMD for addons does not work as documented. If you don't want to change the UMD, you should at least change the docs. There are lots of beginners pulling their hair out because of this little gotcha.
+1 This would make things nice & straightforward for simple projects not using a module system.
xterm addons should be loadable without a module system, using a
<script type="application/javascript">tag.
UMD is a steaming pile of garbage. This hasn't been fixed in over 2 years.
Do you guys even still support your own project? I see you tinkering away at adding little things meanwhile some of your addons are broken. Either remove the addons system or remove the offending plugins. Or better yet. Fix them. But whatever you do don't leave a ticket open for 2+ years an expect anyone to still care about your project.
@talkquazi pretty much every long term project will have issues open for over 2 years, this is but one of them with a whopping 2 upvotes.
We clearly support it, don't be an asshole or you'll get banned form the project. This thing literally contains many thousands of hours of work, most of which was done for the love of it and is being given away for free.
Ok ban me. I don't care. You aren't even following your own edict guidelines talking trash and cussing at me. Please ban me then since you are all high and mighty and you leave tickets open for two years with no progress. Go right ahead child.