ES6 modularisation

[131]

Fix #158

Slice code in ES6 module.

Compositionhelper, viewport & eventemitter are proper ES6 classes.
The Terminal classe is big, yet wcwidth and escapeSequence have been sliced too, this increase overall readability and testing scope. ( slicing can be done on other parts of Terminal class, if desired)

Tests are fine
Documentation generation is fine

new pm task

• npm run build:dist to build standalone version ( exactly same signature as current version) in /dist folder

Strongly simplify demo/app.js (server side)
no need for external fetch, just use WS socket all along
Strongly simplify demo/index.html / demo/main.js

Strongly simplify addon design & loading

in package.json
node_modules/.bin is in npm run path, so no need to set it

[131]

@parisk , it it possible for you to create a v2.0 branch ? I think my PR will be easier to merge in a dedicated branch (not in master), for now.

[Tyriar]

@parisk let's pause all commits on master until we merge one of the fix for #158, merging will be a nightmare if any commits go in. I'm working on the ts solution now.

[131]

I'v also fixed the 'document' isolation (spawing new Terminal in nodejs is no longer an issue), no "hacks" are needed anymore here

[parisk]

@Tyriar yep. Let's not merge anything until we sort out the build system.

Adding labels to all PRs.

[131]

FYI i've successfully tested this branch against Visual Studio Code.
Note that VSCode is an electron app and just "require('xterm')", hence, works with the RAW es6 files of this branch (not the /dist/ folder !!)

[131]

I just understood that @Tyriar works for MS 😆 !

I LOVE VISUAL STUDIO CODE ❤️

[131]

@parisk Ok, last bug was epic.
I just created a sourcelair account, imported xterm.js project and got everything working (until this binding bug)

This was so meta, fixing xterm.js in a sourcelair / xterm.js (with a vm containers everywhere)

[Tyriar]

@131 ❤️

[jerch]

@131 You removed the additional side communication for resizing from the demo. Your replacement does a string vs. buffer (binary data) distinction instead. Will this work for all browser engines?
Also the ASCII limitation could be lifted with a real UTF-8 conversion (a pity TextEncoder is in such an early stage, would make it usable for arbitrary jsonified content in a reasonable runtime).

[131]

1. for the WS-only channel (as i dropped the REST process), binary distinction will work on all browsers yes.
2. A real UTF-8 conversion is "easily" atteignable using new Buffer(JSON.stringify(stuff), 'utf-8'), yet, i didn't want to increase the generated file with browserify/buffer polyfill.

[jerch]

1. Sweet, than this is the real solution for the problem. We had a discussion about it before here demo resize issue #171 and ended up with the additional communication approach.
2. Yeah no need for any bloatware in the demo, it gets the job done.

[parisk]

While I lean more towards TypeScript now that I took a deeper look at it and @Tyriar's PR, I would like to make one main comment here: could we leave demo refactoring out of this, in order to reduce to-be-reviewed code?

Also may I ask we did you decide to introduce the index.js files?

[parisk]

Would I help if I moved the addons directory into src in the meantime (#250)?

[Tyriar]

@parisk When they're named index.js they can be included in node using require('./addons/fit'') (vs require(./addons/fit/fit), this is probably the reason for the switch. It would look a bit funny in a script tag though <script src="addons/fit/index.js"></script>

[131]

@parisk , moving addons is not mandatory actually it end up quiet nice the way it is now :

Im targetting a sane loading API
for user usin umd modules (and browserify/ webpack) just

(see demo/main.js)

var Terminal = require('xterm')
// aplly addon using
require('xtem/addon/fit)(Terminal)

And for user using the /dist edition

(see dist/index.htmljs)

< script src=xterm/xterm.js/>
<script src=xterm/addon/fit.js->

[parisk]

Please wait for a minute. I think I am preparing a quite simpler PR.

[131]

Sorry i'vnt seen your message (now waiting)
FYI : last commit is epic
(i'll push -force it in a few, i missed that "static" keyword is ES6 standard)

[131]

ES6 conversion is complete, xterm.js is fully ES6 AND did not even loose commit/blame/history (no indentation change)

[parisk]

It seems that when I was referring to a minute, I meant 3 hours...

I started getting scary with the magnitude of these PRs, so I started a new smaller one (strictly less than 200 additions), in order to move things forward gradually, instead of all at a time.

Could you please take a look at #251?

[131]

I guess it is a big change !

[parisk]

Sorry about being late to reply here but my main issues with this PR were:

1. difficulty in reviewing (it included thousands of additions and removals)
2. introduction of additional logic than the one described in Introduce some build system to enable more than one js file #158

Despite that I would like to thank you very much for your contribution as it motivated me to open #251!

Please feel free to open up an issue to change the demo protocol if you would like to take over this task 😊 .