[TIMOB-24610] Support transpiling user JS code to ES5, or minimum target OS/JS engine support

[sgtcoolguy]

JIRA: https://jira.appcelerator.org/browse/TIMOB-24610

Description: Support transpiling user JS code to ES5, or minimum target OS/JS engine support

• Use babel-core and babel-preset-env to transpile user code during builds
• For iOS, use the 'iOS' babel-preset target matching our iOS min sdk version (8 currently) if using jscore, otherwise set no target (which should mean transpile everything down to es5).
• For Android, use the chrome target matching the v8 version we're on. (i.e. v8 6.2.x -> Chrome 62)
• I tried to retain as much of the "incremental build" logic as I could. Basically, we minify/transpile if necessary, then compare the output versus the original file. If no changes, we don't write the new contents - we symlink/copy as possible. On iOS, we even check if the new contents differ from the existing contents at the destination to determine if we need to write the file out or not.

[hansemannn]

Tests

iOS

• Build for simulator
• Build for device
• Build for ad-hoc
• Build for app-store
• Incremental build

Android

• Build for simulator
• Build for device
• Build for play-store
• Incremental build

Windows

(@ewanharris / @infosia, can you help here?)

• Build for simulator
• Build for device
• Build for store
• Incremental build

Alloy

• iOS FAILED
• Android
• Windows

Test-Case

class Application {
        
    constructor(cb) { 
        this.window = Ti.UI.createWindow({
            backgroundColor: '#fff'
        })

        var btn = Ti.UI.createButton({
            title: 'Trigger'
        });

        btn.addEventListener('click', () => {
            Ti.API.info('Hello world!');
        });

        this.window.add(btn);
    }
    
    open(cb) {
        this.window.open();
    }
}

var app = new Application();
app.open();

Doing more advanced tests now.

[hansemannn]

@sgtcoolguy Did you test against live-view so far?

[sgtcoolguy]

@hansemannn I did not. I did simple smoke tests to verify the test app and basic app worked on iOS/Android and that we used the correct target presets based on the platform/engine.

I honestly have no idea how liveview works with something like minification/transpilation (ala Alloy).

[ewanharris]

@hansemannn For this to be tested against Windows it will need to be added to the build there.

[hansemannn]

Tried using the PR on studio, but using the latest studio update, it now sees the ES6 syntax as an error and the iOS build options are not available anymore..

[sgtcoolguy]

Studio is still not ES6-aware, which is an entirely separate issue. I have a long-standing feature branch to replace the JS parser in Studio with Oracle's ES6-compliant parser, but I don't know when Kondal and company will be able to pick that up and get it done. (or me, if that's the next priority for me).

[build]

	Warnings
⚠️	🔒 Changes were made to package.json, but not to package-lock.json - Perhaps you need to run npm install?

	Messages
📖	💾 Here's the generated SDK zipfile.

Generated by 🚫 dangerJS

[sgtcoolguy]

@hansemannn @janvennemann ping. Are we good for QE?

[hansemannn]

We should sync it with the Alloy- and Studio-changes, otherwise devs will be confused about our actual support, as most of them use Alloy these days. Still wasn't able to verify Alloy, so maybe @feons could help here. This PR is approved though!

[janvennemann]

Agree with Hans, this PR looks good but i'd say we need to fix the Alloy issues first so QE can test everything at once.

Also tested with Alloy on Android and that errors out with Uncaught TypeError: Cannot read property '_' of undefined. That's caused by the replacement of this with undefined and can be solved by updating underscore.

[sgtcoolguy]

I understand we want all the different parts to support es6+ at once, but I strongly disagree with holding this PR (or a Studio or Alloy one) for the others if they're not explicitly required by the others.

We have separate tickets for adding support for ES6 to the various tools and products. If we hold off until hey all support ES6 we won't make any progress for a long time.

There's still value in getting this working for classic apps built by the CLI or the new atom plugins.
If you're saying that this PR explicitly breaks alloy apps, then that is a separate issue and I can try and address that by effectively disabling transpilation (or parts of it) for alloy apps until we fix Alloy.

[sgtcoolguy]

It looks like tidev/alloy#852 and tidev/alloy#842 are related then?

[hansemannn]

@sgtcoolguy You are right, it's probably better to unblock general ES6 (do we support ES7 and async / await with this as well?) here and do Alloy separately. I think it's also a good reason for an Alloy v2 to support ES6, so people will know that there are breaking changes like the above.

[janvennemann]

@sgtcoolguy, sorry if it wasn't clear, but yeah i meant that this breaks Alloy and we should at least solve that. The PRs you mentioned should do exactly that. My intention was not hold everything off until ES6 support is available for all but at least keep things working :)

[hansemannn]

Just tested it with Alloy and if we don't use ES6, the build seems to be fine. So we could merge this one and do Alloy v2 with the updated underdash / lowdash next?

[hansemannn]

I've updated the lodash PR to resolve the merge conflicts, let's do this!