[feature?] Plan for bundling ES modules?

[subhaze]

Currently, the only way I know how to bundle JS files is with the good o'l // @codekit-append/prepend.

This has worked great, but, now that things are venturing into the ES.Next world I was curious if you'd put thought into doing bundles with something like systemjs or amd?

You could have some restrictions in place like the latest typescript compiler where bundling only works when using either of those two module export types.

Or will this be in hook land?

[codebryo]

In general a very good and important question. although there are so many module exporters. Rollup, Browserify and Webpack are pretty standard. I guess its hard to narrow done what to support.

[subhaze]

I think we're mixing two things in the above as one thing. There are many module formats/export types, but Rollup, Browserifiy, and Webpack are not one, they're just bundlers. UMD, AMD, CJS, SystemJS are the common ES Module -> ES5 "modules."

With that list of Module formats, two of them have built in bundlers, SystemJS and AMD which could help simplify the process. The complex thing would be mapping what files needed to be processed due to import something from "some_ES_Module", where "some_ES_Module" would need to be included into the output as SystemJS/AMD and any of its imports as well.

I'm not trying to say that it would be "simple" but it's definitely doable and less complex than trying to support some 3rd party bundler when we have Module formats with 1st class bundle support. So that in itself narrows down support.

TypeScript with the allowJs flag set and outputFile set will produce a bundle from AMD/SystemJS easily, and that's what I've been using hooks for since I can't pass all the options needed currently in CK to appease TypeScripts CLI commands. So there's a, at least semi, sane way but would definitely have to be strict rules in place.

I'll see if I can get some sample projects up with hooks if that would help the cause.

[bdkjones]

Yea... goddamn JavaScript.

The bottom line here is that I don't know what to do about modules. Long-term, the language itself will contain module-loading. Until then, there's like 500 competing standards and they all require really complex syntax and polyfills and crap that the average user just doesn't want to mess with.

I was considering implementing Browserify, but I'm just not sure it's standard enough yet. I am open to discussion on the topic. It would also GREATLY help if people provided actual examples of how they use modules (literally, code samples). I'm not up to date on the best practices here because I try to avoid writing JavaScript whenever possible.

[subhaze]

I'm down from coming up with some code samples.

I'd say if CodeKit stuck with what was introduced in ES2015 specification (aka ES6), the ES Module, it'd be in a good spot since this "is" the direction that the JS module system is going. While the others, AMD, CJS, UMD, SystemJS, were just a stepping stone to get there. It will, however, have to "choose" what format to transform the code to and I see SystemJS being a great target. And, really, in the end the user shouldn't care what format is used for the bundle so long as it "just works" in the browser and allowed them to use their own ES Modules or any that are being produced by 3rd party libs.

Not supporting import {blah} from "some/cjs/or/amd/or/etc/module";, to me, seems valid since those aren't the official spec and introduces crazy complexities on how things are transformed and in what order.

Below is a link to what import statements look like, which I'd say is really the only part that CK would care about, so that it knew what files being saved should cause a rebuild of the the file. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import

Also, sticking with just ES Modules makes things a lot saner and since it's in the JS spec, holds water on why it was the one selected.

If this doesn't make it, definitely understandable, but hoping for a valiant attempt :)

[ and if anything the tsc compiler already does this kind of bundling, but, I can continue to bug you about that on a different ticket :P ]

[subhaze]

Here is one example using some very small ES Modules. https://github.com/subhaze/ck3_test1/tree/modules/system_js

current workflow

Right now I've a hook setup that basically says anytime a .js file is put into build/ run the systemjs-builder on main.js.

I've babel setup to use all the ES2015 options + produce Systemjs Modules from my ES Module syntax.

the dream workflow

Have an option in CK on main.js to have something like [✓] bundle imports in the right handle panel when that file is selected.

Once that's checked any files that are imported via ES Module Syntax in main.js are watched for updates and trigger a bundle to be produced when they change.

Having CK doing the bundling behind the scene, I'd expect to not see any of the other files in the build/ as they are now (since they're needed for me to do the bundling) unless I specifically told CK to do so.

[Update]

You should see the following in the JS console when previewing index.html loading in the bundle.js that was produced.

bundle.js:14 I'm a side effect, because I was imported somewhere (nest/nested.js)
bundle.js:40 moar
bundle.js:44 something

[bdkjones]

I don't think you need the Hook for the TypeScript approach. I've been silently passing the -allowjs flag to TSC in the last couple releases of CodeKit 2.x and in 3.0

There did not seem to be a downside to always passing it.

[subhaze]

Oh wow, hmm, guess I'll have to try using a .ts file as an entry point so CK will compile it via tsc and just import .js files from there. Thanks for the heads up on that!

Since they're pushing TypeScript to be a superset of JS, thoughts on adding options for "Transpile with:" to be nothing/babel/typescript ?

Having that could possibly be a pretty good path to having away to bundle imports in JS files.

[subhaze]

It worked!

There's a bit of work still to get things working correctly with the typescript version because they're bundling system without the self-execution like in my example branch above.

But, it's relatively simple to do, example branch https://github.com/subhaze/ck3_test1/tree/modules/typescript

Here, I just created main.ts so that CK would process it as typescript, then just had it import my ES Modules.

The index file had to be updated to include the System registering code ('cause they don't bundle with it 😦 ) but... simple enough to add that, then include the execution part System.import('main').

Im going to try and block some time off on Saturday to write up a blog post, this is a game changer!! At least for me... :P

[Update]

Unfortunately since the imports aren't tracked, when updating a dependency a new bundle isn't built... So, Hook is still kinda needed to ensure things are rebuilt. :/

[subhaze]

An example of using browserify. https://github.com/subhaze/ck3_test1/tree/modules/commonjs

We take our ES Modules and use Babels transform to commonjs plugin to produce modules browserify knows.

from there we just have a hook listening for any .js file that enters build/ and then runs our build process to create build/bundle.js

[subhaze]

Example of using rollup for bundling. https://github.com/subhaze/ck3_test1/tree/modules/rollup

Here we're using babel to transpile, important part is to not use the preset es2015 so that babel doesn't mess with the ES Module import statements.

from there a hook is ran everytime a .js file enters build/ and then we run npm run build which runs rollup on the main.js file and outputs to bundle.js

[subhaze]

@bdkjones do any of the branches on that repo help? Need moar ES Module examples? I really feel CK is close to a viable bundling system for JS and great work on getting babel in as well. Has been a pretty solid beta so far.

[bdkjones]

So what does the ECMA2015 spec say about import syntax with regards to relative and non-relative import paths? That is, suppose I write:

import * from "someModule"

vs

import * from "./someModule"

TypeScript has its whole "Look in node_modules folders all the way up the directory tree" approach. What is the ES standard? Is there one, or are paths always expected to be relative?

[subhaze]

So... There currently isn't an official "standard" for the Module Loader as it's still being worked out. However, TS and SystemJS are following, as closely as they can, to what should be the spec since they're looking for parity of TS module loading and ES Modules.

Sticking with the './ relative approach seems to be the way to go IMO since every polyfill/lib has moved in that direction that I know of when dealing with proper ES Modules.

[bdkjones]

Ok. Beta 5 now includes an ES 6 Imports section in the JavaScript file inspector that shows files linked with an import statement. Likewise, Beta 5 now scans JS files for import statements and links files correctly, so long as they are relative.

JS import statements are not compatible with CodeKit Frameworks; you cannot import a file from a Framework because the path needs to be relative.

The legacy @codekit-prepend/append statements are still supported, of course, but I'm not sure how well they'll mix with import. I would not use both. I'm also not sure if the presence of import statements will muck up the ordering of prepend/append items.

[subhaze]

@bdkjones woot!

So... one final thing, the prefix 'ES2015' for Babel does use CJS to wrap the code up, however, it is just that. So it's not usable in the browser without one final step, which, with CJS you'd need to run browserify on the output file.

The above can, now, very very very easily be done with a hook, which would allow us to use whatever we wish, CJS/AMD/UMD/SystemJS.

I guess... what I'm trying to get at is, it's very manageable the way CK handles imports now, since you don't have to run a greedy ass hook (basically triggering on all JS files) to do the compiling, while using BASH to loop through files, and stand on one leg while juggling and solving rubix cubes; you rock for this man, need to buy ya a beer or two.

You can now rely on CK to produce a nice, ready to transform, module concatenation, much awesomeness.

BUT, if you wish to give the users a no hook needed option for, bundled, browser ready code. You'd have to pick a poison, which is currently CJS if you go the prefix route, then the final file would have to be ran through browserify.

I'd honestly vote on drinking the systemjs poison since it's the closest to behaving exactly the way ES Modules are intended to work. BUT it may make your life easier on the explanation side of things to:

• Just use the ES2015 preset, and it'll bundle.
• Or take the easiest route and leave things as is and explain that a hook will be needed for final output :) -- (which I'd be happy to write up posts for using each the way it's currently working)

[/wall-of-text-with-random-letters-making-even-more-random-words] #deadlines #betatesting #makeCKgreatagain

[bdkjones]

What is the systemJS approach?

On 31 May 2016, at 12:23, Michael Russell <notifications@github.com mailto:notifications@github.com> wrote:

@bdkjones https://github.com/bdkjones woot!

So... one final thing, the prefix 'ES2015' for Babel does use CJS to wrap the code up, however, it is just that. So it's not usable in the browser without one final step, which, with CJS you'd need to run browserify on the output file.

The above can, now, very very very easily be done with a hook, which would allow us to use whatever we wish, CJS/AMD/UMD/SystemJS.

I guess... what I'm trying to get at is, it's very manageable the way CK handles imports now, since you don't have to run a greedy ass hook (basically triggering on all JS files) to do the compiling, while using BASH to loop through files, and stand on one leg while juggling and solving rubix cubes; you rock for this man, need to buy ya a beer or two.

You can now rely on CK to produce a nice, ready to transform, module concatenation, much awesomeness.

BUT, if you wish to give the users a no hook needed option for, bundled, browser ready code. You'd have to pick a poison, which is currently CJS if you go the prefix route, then the final file would have to be ran through browserify.

I'd honestly vote on drinking the systemjs poison since it's the closest to behaving exactly the way ES Modules are intended to work. BUT it may make your life easier on the explanation side of things to:

Just use the ES2015 preset, and it'll bundle. Or take the easiest route and leave things as is and explain that a hook will be needed for final output :) -- (which I'd be happy to write up posts for using each the way it's currently working) [/wall-of-text-with-random-letters-making-even-more-random-words] #deadlines #betatesting #makeCKgreatagain

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdkjones/codekit3/issues/11#issuecomment-222793058, or mute the thread https://github.com/notifications/unsubscribe/AA4jZjjfoMdLeW90aNb7MO4fJyFK4F4Pks5qHIq1gaJpZM4Ih30F.

[subhaze]

I'll find sometime tonight to play around with things to ensure all is working the way it seems it should and send ya a sample project zipped up.

[subhaze]

But to answer their approach quickly, they handle circular dependencies, whether that's a "good thing" to have... is def debatable, but it's in the spec and it's something that CJS can not handle.

[subhaze]

Had a bit of time before end of work day so threw this together. It doesn't work quite the way I thought it would.

I was thinking CK would concat the files together like TypeScript does but it doesn't appear to, or I may be missing something. So, for this method to work you'll have to ensure that all the .js files have moved over into the build folder.

Anyhow, this still leads to a simple hook which is setup for when 'main.js' enters the build/ it'll run the system bundler. I've added the node_modules so the zip is a bit large'ish, but figured it would be easier if it just worked without npm installing crap.

system-js.zip

[bdkjones]

I don't know how to concat the files together. When you write:

import {crap, moreCrap} as lib from "./someFile"

It doesn't seem like I should just throw the contents of someFile.js into the base file in place of that import statement. I think I would be expected to walk someFile.js, look for the export statement for crap and moreCrap and then write a function exposing those as a property of a lib object.

All of that requires parsing the entire JS file with an AST, etc. CodeKit can't do that when linking import statements; that has to be done by the JS compiler (whatever it ultimately is...babel, browersify, etc)

[subhaze]

concating system and amd style modules would be totally fine, there are tools like RollupJS that are trying to solve what you describe "It doesn't seem like I should just throw the contents of someFile.js into the base file". But, at the end of the day, since all js code isn't local to the client, the client must DL the contents of ./somefile in its entirety to get crap, moreCrap anyhow.

babel can't concat, but if you take the output files (if AMD or system) and concat those together. All the end user has to do is either load amd.js or system.js at the top before including the concat'd code.

Babel (with system module selected) will take:

import {moar, other} from './moar';

moar();
other();

import './sideeffect';

and produce:

System.register(['./moar', './sideeffect'], function (_export, _context) {
  "use strict";

  var moar, other;
  return {
    setters: [function (_moar) {
      moar = _moar.moar;
      other = _moar.other;
    }, function (_sideeffect) {}],
    execute: function () {

      moar();
      other();
    }
  };
});

moar.js

import * as _other from './other';

export function moar(){
    console.log('moar');
}

export function other(){
    console.log(_other.something);
}

export function leftover(){
    console.log('a left over');
}

to:

System.register(['./other'], function (_export, _context) {
    "use strict";

    var _other;

    return {
        setters: [function (_other2) {
            _other = _other2;
        }],
        execute: function () {
            function moar() {
                console.log('moar');
            }

            _export('moar', moar);

            function other() {
                console.log(_other.something);
            }

            _export('other', other);

            function leftover() {
                console.log('a left over');
            }

            _export('leftover', leftover);
        }
    };
});

and so on, wrapping each file (ES Module) in a System.register closure.

The {crap, moreCrap} syntax is more for scoping, basically just requesting a small bit of a module into your scope without injecting everything that ./something had in it.

I compiled the main.js in the system-js.zip for a comparison. Here is the output TypeScript does when you do the following in source/ tsc --allowJs -m system main.js --outFile bundled.js

bundle.js

System.register("nest/nested", [], function(exports_1, context_1) {
    "use strict";
    var __moduleName = context_1 && context_1.id;
    function nested() {
        console.log('nested');
    }
    exports_1("nested", nested);
    return {
        setters:[],
        execute: function() {
            console.log("I'm a side effect, because I was imported somewhere (nest/nested.js)");
        }
    }
});
System.register("other", ["nest/nested"], function(exports_2, context_2) {
    "use strict";
    var __moduleName = context_2 && context_2.id;
    var something;
    return {
        setters:[
            function (_1) {}],
        execute: function() {
            exports_2("something", something = 'something');
        }
    }
});
System.register("moar", ["other"], function(exports_3, context_3) {
    "use strict";
    var __moduleName = context_3 && context_3.id;
    var _other;
    function moar() {
        console.log('moar');
    }
    exports_3("moar", moar);
    function other() {
        console.log(_other.something);
    }
    exports_3("other", other);
    function leftover() {
        console.log('a left over');
    }
    exports_3("leftover", leftover);
    return {
        setters:[
            function (_other_1) {
                _other = _other_1;
            }],
        execute: function() {
        }
    }
});
console.log('another side effect');
System.register("main", ["moar", './sideeffect'], function(exports_4, context_4) {
    "use strict";
    var __moduleName = context_4 && context_4.id;
    var moar_1;
    return {
        setters:[
            function (moar_1_1) {
                moar_1 = moar_1_1;
            },
            function (_2) {}],
        execute: function() {
            moar_1.moar();
            moar_1.other();
        }
    }
});

This could be starting to complicate things, and with the current import updates you made, woot!, def eases using a third party tool to do the bundling. Just trying to think of ways to have at least one route of bundling in CK native and if you wished to go further jump into hooks.

It's early and I've not had coffee... So I hope all of the above makes sense... I'll re-read later, or just ping me with "The hell'd you say?"

[subhaze]

Yeah, it's me again... hi!

So... Looking through how babel is working with systemjs, babel isn't adding the ("filenamehere", [...]) when transpiling down to that module format like TypeScript does, so just concating when using that module format wont fly...

I played around with rollup last night and it appears to handle the circular dependencies as it should and follows along with the working loader spec as far as I can tell, and is committed to following along with it from what I've read in the issues/pull-request threads. They also have a no BS mindset, don't do all the things loader, do the one thing right loader, it's straight ES Modules or bust. Which is great IMO.

My main question is, how reasonable would it be for CK to work kinda like SCSS for JS. When CK sees there's linkage between files and a linked file is saved, CK would run rollup on that file. Which does all the concatenation (buillds the AST and all that jazz) and ONLY pulls in the code you need (basically what you were talking about above). So, you end up with a file that only has the code you need. After that, then process the file however the user specified to do, such as use babel with XYZ plugins.

[bdkjones]

Does rollup support ES7 and all that crap? If not, we have to run Babel first. I'm not opposed to integrating another tool and producing a single output file---that's the ideal goal. Does rollup also allow you to combine files via the CLI? That would be perfect for handling the legacy @codekit-prepend statements.

-Bryan

Sent from my iPhone

On Jun 3, 2016, at 06:40, Michael Russell notifications@github.com wrote:

Yeah, it's me again... hi!

So... Looking through how babel is working, babel isn't adding the ("filenamehere", [...]) when transpiling down to that module format like TypeScript does, so just concating when using that module format wont fly...

I played around with rollup last night and it appears to handle the circular dependencies as it should and follows along with the working loader spec as far as I can tell, and is committed to following along with it from what I've read in the issues/pull-request threads. They also have a no BS mindset, don't do all the things loader, do the one thing right loader, it's straight ES Modules or bust. Which is great IMO.

My main question is, how reasonable would it be for CK to work kinda like SCSS for JS. When CK sees there's linkage between files and a linked file is saved, CK would run rollup on that file. Which does all the concatenation (buillds the AST and all that jazz) and ONLY pulls in the code you need (basically what you were talking about above). So, you end up with a file that only has the code you need. After that, then process the file however the user specified to do, such as use babel with XYZ plugins.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[subhaze]

tis CLI, and it doesn't support any kinda of JS syntax feature other than imports, it focuses solely on import/export. So you could write ES5/6/7/8/9/2020/JSX/JSZ/whatever, all it cares about/does is look for import/export syntax and produces a combined output. Which is why you'd need run it, then push that code through Babel/TypeScript/Traceur/etc... so that the syntax is transformed to whatever target you're looking for ES5/3

[subhaze]

The issue with "we have to run Babel first" is that Babel will muck with your ES6+ module syntax. The ES2015 preset so kindly (sarcasm) converts all your import and export to CJS style module syntax.

[subhaze]

Here is an example using CK and rollup with a hook.

I set Babel up to not touch my ES Module import/export code and just do the syntax transformations.

from there I just run rollup -f iife -o ../build/bundle.js ../build/main.js

https://github.com/subhaze/ck3_test1/tree/modules/rollup/source

[bdkjones]

But if rollup is creating an AST to do its thing, how does it do that without supporting the bleeding edge syntax? That's my concern. If rollup has to first, can you still write the bleeding edge syntax from ES 7 and have it work?

Sent from my iPhone

On Jun 3, 2016, at 09:08, Michael Russell notifications@github.com wrote:

The issue with "we have to run Babel first" is that Babel will muck with your ES6+ module syntax. The ES2015 so kindly (sarcasm) converts all your import and export to CJS style module syntax.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[subhaze]

( >m ) yeah, you're right... just tried decorator on a function... and yeah, busted on that... crap... ok yeah... babel would def need to be ran first... totally missed that, sigh.

So yeah, it'd have to operate like the hook example I linked above, which sucks since then you'd have some complexity on the user side of clicking the correct checkboxes...

[subhaze]

I keep banging my head on this cause CK is sooooooo close to not needing any external dependencies for bundling up JS code. Well, technically it has one, via TS which I'm using in this beta with a current project I'm working on.

I just know this is a feature the devs at my work are wanting, and I'm sure others as well.

[subhaze]

They have a plugin that works with babel, but i'm not sure how ideal this would be integrated into CK natively, due to the config setup... https://github.com/rollup/rollup-plugin-babel

[bdkjones]

Walk me through how we can do this with TypeScript, again? If I have a bunch of JS files using ES7 syntax and I transpile them with Babel to “myfile.js” (which is going to include a bunch of commonjs-style requires), can we effectively use TypeScript to produce a bundled output file?

On 3 Jun 2016, at 09:26, Michael Russell notifications@github.com wrote:

They have a plugin that works with babel, but i'm not sure how ideal this would be integrated into CK natively, due to the config setup... https://github.com/rollup/rollup-plugin-babel https://github.com/rollup/rollup-plugin-babel — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdkjones/codekit3/issues/11#issuecomment-223626211, or mute the thread https://github.com/notifications/unsubscribe/AA4jZqnFuMGLZc-0yrPHc0xSc8l2nvvSks5qIFW2gaJpZM4Ih30F.

[subhaze]

Unfortunately not quite. The TypeScript route, is just that. It does all the ES6/7 transpiling on its own then produces the output.

We could use TS if Babel didn't use the CJS-style as the default.

My current workflow with TS can be found on this branch https://github.com/subhaze/ck3_test1/tree/modules/typescript/source I basically have a bundle.ts file that only imports JS files, so that I don't have to deal with TS strict typing and all that jazz.

Since Babel does that by default, It should be safe to use browserify for bundling https://github.com/subhaze/ck3_test1/tree/modules/commonjs/source uses a hook that browserifies the output from ES2015 preset of babel.

[subhaze]

There's a route to bundling on any of the current Babel Module Transform plugins.

if amd -> cli via requirejs if cjs || es2015preset -> cli browserify if systemjs -> cli jspm || small node script with systemjs if umd -> would have to look into, but browserify prolly has a transformer for it

I'm just not sure how feasible the above would be to support... I've example hooks for all the above but UMD, for the post processing of js files.

[bdkjones]

Yea, to hell with allllllllllll of that noise. Browserify is a nightmare; I have worked with it in the past. It sounds like rollup is going to be the way to go, with the Babel plugin.

But the question is how to handle the @codekit-prepend/append legacy. Convert them to import statements automatically? Is that even do-able? Can you write: import * from './jquery.js' and have it work?

Modules are still overkill for folks that just want to combine a few scripts. How do es6 imports work in that case---where the imported script has no "export" statements; it's just some lines of JavaScript?

Sent from my iPhone

On Jun 3, 2016, at 09:55, Michael Russell notifications@github.com wrote:

There's a route to bundling on any of the current Babel Module Transform plugins.

if amd -> cli via requirejs if cjs || es2015preset -> cli browserify if systemjs -> cli jspm || small node script with systemjs if umd -> would have to look into, but browserify prolly has a transformer for it

I'm just not sure how feasible the above would be to support... I've example hooks for all the above but UMD, for the post processing of js files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[subhaze]

yeah, I figured all that if if if if was way too much crap.

as for @codekit-prepend/append.

@codekit-prepend == import './somefile' so replacing those to import './somefile' should suffice, unless something changes between now and final spec, but that's currently how all the module loaders that mimic ES do it that I've used. I'm just not sure about the append.

How do es6 imports work in that case---where the imported script has no "export" statements;

You would just import that as import './sideeffect' as they're basically just side effect files, which behave like ck-prepend, take code from file, inject code in.

I'm just trying to think how I'd expect that one to work (append)... And I just feel like it would be append at the end of the main file before processing through babel/rollup.

this:

// @codekit-prepend: 'somefile.js';
// @codekit-append: 'otherfile.js';

import * as someNameSpace from './myawesomelib';
import './aSideEffectFile';

function someCode(){
    // ...
}

let foo = 'bar';

const API_KEY = '0123456789';

to this:

import './somefile';
// @codekit-append: 'otherfile.js';

import * as someNameSpace from './myawesomelib';
import './aSideEffectFile';

function someCode(){
    // ...
}

let foo = 'bar';

const API_KEY = '0123456789';

// contents of ES6+ otherfile.js
let otherThings = () => 'otherThings';
const moreOtherStuff = 'moreOtherStuff';

[robstown]

I am trying to get modules to work in CK3 but have been unsuccessful. Would it be possible for someone to write a short summary of how to configure CK3 to get modules to work correctly?

[subhaze]

@robstown would you be apposed to using TypeScript as the ES 6 transpiler? I ask this because that's, currently, the only way to use CK without a hook to bundle. If you want to use babel, hooks + third-party tools would be involved.

[robstown]

I'm not opposed to it, although I was under the impression that CK3 used either CommonJS or rollup to generate a compiled build from the import and export statements? I was hoping to just use the ES6 syntax and have CK3 bundle. Is this how it was implemented? I followed through the conversation in the issue write-up but wasn't able to reproduce a bundled build. Thanks.

On Sun, Aug 28, 2016 at 6:05 PM, Michael Russell notifications@github.com wrote:

@robstown https://github.com/robstown would you be apposed to using TypeScript as the ES 6 transpiler?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdkjones/codekit3/issues/11#issuecomment-243002418, or mute the thread https://github.com/notifications/unsubscribe-auth/APlUVOdp1NQUCoPCqbPwi2WJwBw0oBHiks5qkgYdgaJpZM4Ih30F .

[robstown]

...to clarify, I though babel was being used as the transpiler prior to bundling. It seems that way from the comments and build notes anyways.

On Mon, Aug 29, 2016 at 10:14 AM, Rob Searle rob@searlegroup.com wrote:

I'm not opposed to it, although I was under the impression that CK3 used either CommonJS or rollup to generate a compiled build from the import and export statements? I was hoping to just use the ES6 syntax and have CK3 bundle. Is this how it was implemented? I followed through the conversation in the issue write-up but wasn't able to reproduce a bundled build. Thanks.

On Sun, Aug 28, 2016 at 6:05 PM, Michael Russell <notifications@github.com

wrote:

@robstown https://github.com/robstown would you be apposed to using TypeScript as the ES 6 transpiler?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdkjones/codekit3/issues/11#issuecomment-243002418, or mute the thread https://github.com/notifications/unsubscribe-auth/APlUVOdp1NQUCoPCqbPwi2WJwBw0oBHiks5qkgYdgaJpZM4Ih30F .

[subhaze]

Currently CK only tracks dependencies of ES Modules, but no bundling is done. The dependency tracking does, however, allow to write more performant hook since CK now knows when related files are edited and a new process should happen. The hook route does unfortunately require a third-party tool, such as browserify/rollup/etc... to be included within the project.

If you're interested in only using babel I would say a hook with browserify would be the most seamless approach, this is because the es2015 preset is using commonJS as the alternative to ES Module import statements. So, it should "just work" so long as you've a hook setup.

If you're ok with having one TypeScript file, and the rest being .js files and pure ES 6 then CodeKit can use the current TypeScript tool to transpile your ES 6 code into ES 5 and TS will bundle that code into either SystemJS or AMD modules. From there you would just need to include either of the two files and bootstrap your single JS file.

I'm aiming to write up a few articles on this, I've just been waiting to see where all this goes + I'm kinda of strapped for time. But, writing this up for others is definitely a priority of mine (which is why I asked on your preferred approach) when life settles down a bit for me :)

[robstown]

Thanks for you help, that's awesome!!!

On Mon, Aug 29, 2016 at 10:30 AM, Michael Russell notifications@github.com wrote:

Currently CK only tracks dependencies of ES Modules, but no bundling is done. The dependency tracking does, however, allow to write more performant hook since CK now knows when related files are edited and a new process should happen. The hook route does unfortunately require a third-party tool, such as browserify/rollup/etc... to be included within the project.

If you're interested in only using babel I would say a hook with browserify would be the most seamless approach, this is because the es2015 preset is using commonJS as the alternative to ES Module import statements. So, it should "just work" so long as you've a hook setup.

If you're ok with having one TypeScript file, and the rest being .js files and pure ES 6 then CodeKit can use the current TypeScript tool to transpile your ES 6 code into ES 5 and TS will bundle that code into either SystemJS or AMD modules. From there you would just need to include either of the two files and bootstrap your single JS file.

I'm aiming to write up a few articles on this, I've just been waiting to see where all this goes + I'm kinda of strapped for time. But, writing this up for others is definitely a priority of mine (which is why I asked on your preferred approach) when life settles down a bit for me :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdkjones/codekit3/issues/11#issuecomment-243141130, or mute the thread https://github.com/notifications/unsubscribe-auth/APlUVE0NbhWQE6J2P-8CS1jWI3sUt6j2ks5qku0ggaJpZM4Ih30F .

[robstown]

Michael, I look forward to your blog, my hook doesn't seem to be doing the trick right now. I'll just do things manually for a while. I appreciate your help. -Rob

On Mon, Aug 29, 2016 at 12:23 PM, Rob Searle rob@searlegroup.com wrote:

Thanks for you help, that's awesome!!!

On Mon, Aug 29, 2016 at 10:30 AM, Michael Russell < notifications@github.com> wrote:

Currently CK only tracks dependencies of ES Modules, but no bundling is done. The dependency tracking does, however, allow to write more performant hook since CK now knows when related files are edited and a new process should happen. The hook route does unfortunately require a third-party tool, such as browserify/rollup/etc... to be included within the project.

If you're interested in only using babel I would say a hook with browserify would be the most seamless approach, this is because the es2015 preset is using commonJS as the alternative to ES Module import statements. So, it should "just work" so long as you've a hook setup.

If you're ok with having one TypeScript file, and the rest being .js files and pure ES 6 then CodeKit can use the current TypeScript tool to transpile your ES 6 code into ES 5 and TS will bundle that code into either SystemJS or AMD modules. From there you would just need to include either of the two files and bootstrap your single JS file.

I'm aiming to write up a few articles on this, I've just been waiting to see where all this goes + I'm kinda of strapped for time. But, writing this up for others is definitely a priority of mine (which is why I asked on your preferred approach) when life settles down a bit for me :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdkjones/codekit3/issues/11#issuecomment-243141130, or mute the thread https://github.com/notifications/unsubscribe-auth/APlUVE0NbhWQE6J2P-8CS1jWI3sUt6j2ks5qku0ggaJpZM4Ih30F .

[robstown]

Ugg, I figured it out, symlink hell again!

<node /usr/local/bin/browserify> instead of

[mattpilott]

I am currently struggling to use es6 imports, no idea how to get rollup to work though. From reading this thread it seems I need to make a hook, however i'm hook illiterate. I want to be as close to writing native js as possible, I don't want to bootstrap my code with require or anything. It seems rollup does the best job of bundling and if someone could send me an example hook some way of doing this stuff that would be great and much appreciated.

[Kerrick]

Any news on ES6 imports being handled by CodeKit without having to use the TypeScript workaround?

[bdkjones]

I'm working on it! The major issue is source map support across modules with Babel in the middle. JavaScript is...a disaster.