jspm (mis)configuration with respect to the "dist" folder in skeleton-navigation?

[digizen]

One of the really cool features of jspm is the ability to transpile ES6 files to ES5 on the fly via Babel, Traceur or Typescript. However, it may be misconfigured in this project - I'm looking for someone with more experience with the JS toolchain to tell me if I'm off-base here.

This feature is enabled in the config.js file in the root of skeleton-navigation, so every time you load .js file, the program automatically transpiles it to ES6, obviously incurring a significant overhead, which makes sense when you're doing development work.

But there is also a second path to compilation - this is the gulp "build" task. You can trigger gulp build and it will run the babel compiler and put the output files into "dist" folder, where SystemJS can pick them up. Files can also be bundled and minified when compiling into this folder. I'm pretty sure this is designed for production/distribution, not development.

When you are working with this particular toolchain, you use "gulp watch" to have the system watch the file system so that as you make changes, the browser is restarted. However, funny thing is that the "gulp watch" triggers the "build" on every file change, and in the config.js file you have the following configuration snippet:

"paths": {
   "*": "dist/*",
   ...

This points the configuration to use the "dist" folder for all uses. This implies a couple of things. First, the Aurelia sample programs are compiled twice. Once, every time you save the file, and the second time when the browser is reloaded. This seems wrong.

Second, you cannot debug this app without a "gulp watch" command. I launched "node app.js", and spent two hours hitting my head against the wall trying to figure out why my changes I was making were not being reflected in the app I was running. To make a long story short: I first ended up doing a "gulp build" to recompile the app, then decided the whole thing was silly and changed the "paths" in the code above to the "src" directory, which worked flawlessly. Obviously for deployment and production, this will need to be changed back.

There seems to be an option in jspm, called "setmode" which allows you to switch from dev to production and set some variables - I'm not sure exactly how this is supposed to work - there is a paucity of info on the SystemJS GitHub web portal in respect to this option.

Anyway, I am new to this JS/SystemJS/Gulp toolchain, so I wanted to ask for your thoughts on what I found. Is there something I'm missing perhaps?

Thanks for your insight, Greg

[EisenbergEffect]

Nothing is compiled twice. The starter kit is set up to build code and then compile only the files that change. JSPM will not compile already-compiled code.

Can you elaborate on the debug issue? I haven't had debug issues so I'd like to kn owmore, specifically why you would use node app.js at all in this case.

[digizen]

@EisenbergEffect - thanks for the info. This seems to nullify one of the selling points of SystemJS - the in-browser transpilation.

To explain the debug issue I am experiencing, I first want to mention that I'm attempting to use JavaScript for the frontend as well as the backend of my sample application. To this end, I set up the following project, which wraps the skeleton-navigation sample front-end within a express node.js app back-end:

https://github.com/zewa666/aurelia-node

The problem is that from the start of "gulp watch" to the time the website finishes loading takes a little more than a minute. A refresh of any file takes about 40 seconds to finish loading. I'm running this on a 2-year old Windows i7 laptop with 16GB RAM.

I'm trying to troubleshoot what in the world is taking the "gulp watch" session so long to spin up. If I manually start the back-end (which also serves up the aurelia front-end) using "node app.js" (without typing in "gulp watch", and then manually hit refresh on the aurelia skeleton website in the browser (obviously without browser-sync), the total load time is less than 10 seconds start to finish, which includes me hitting the refresh button.

The reason I originally wrote the above message is that my changes in the "src" directory were not being reflected when I refreshed the page. It turns out that I was missing the "gulp build" step, or alternatively, setting up the "paths" location to "src/*" as I mentioned above.

I'm still very confused about why it takes a minute to spin up the debug environment via "gulp watch". If you have any ideas, I'd love to hear them.

Thanks, Greg

[EisenbergEffect]

This is strange. I've never seen it take that long. On my Mac it takes a couple seconds to initially start the watch task. Then, as I save files, the refreshes to the browser are near instantaneous. It's fast enough that I have felt comfortable using this technique in live presentations for months now. What version of Windows are you running? Could that have something to do with it? Also, how old are your node and gulp installs? Perhaps that has something to do with it.

Regarding the in-browser compile of SystemJS, I do think that is pretty cool. I haven't used it myself as part of my development workflow. I can tell you that our new getting started guide (currently in development) does plan to use a new starter leveraging this capability so we can help developers learn Aurelia faster without having to deal with node, gulp, jspm, etc.

@jdanyow @cmichaelgraham In your Windows work have you encountered this type of long startup issue? Any ideas what might be the cause?

[jdanyow]

It's fast for me too. @digizen if you disable your anti-virus, does gulp watch speed up? I've seen AV clog up my npm/jspm installs by eating a ton of CPU, wondering if something similar is happening to you during the gulp-watch task.

[digizen]

I think I may have figured out at least part of the problem. The repo that I previously mentioned wrapping Aurelia and Express in the same package (at https://github.com/zewa666/aurelia-node) seems to have two separate watch processes set up on the same set of files in the gulp configuration. I think this may be causing contention & slowdown on at least my system.

The gulp config file (https://github.com/zewa666/aurelia-node/blob/master/gulpfile.js) has the following two sections:

gulp.task('watch', ['nodemon', 'browser-sync'], function() {
  gulp.watch(path.source, ['build-system', browserSync.reload]).on('change', reportChange);
  gulp.watch(path.html, ['build-html', browserSync.reload]).on('change', reportChange);
  gulp.watch(path.style, browserSync.reload).on('change', reportChange);
});

and

gulp.task('browser-sync', ['build', 'nodemon'], function() {
  browserSync.init({
    files: ['public/**/*.*'],   // <== This also sets up a watch for all files.
    proxy: 'http://localhost:9000', 
    port: 7000,
    browser: ['google chrome']
  });
});

I'm assuming this is probably specific to zewa666's repo; I didn't see a gulp "browser-sync" step in the aurelia/skeleton-navigation project.

After I commented out the "files" section of the "browser-sync" section, there was a dramatic speedup of "gulp watch" both in startup & refresh. There are still some glitches (browser-sync doesn't always trigger properly) but it's much, much better than it was before. And I'm going to assume that the remaining glitches probably have to do with the way the gulp file was set up by zewa666.

Thanks again for your time, Greg

[plwalters]

That's correct I believe the gulp watch task has to watch like 30k files in that repo at the time of this comment, in case anyone runs in to this down the road just watch less files.

[zewa666]

@digizen hey, may I ask you to open an issue on the aurelia-node project, so we can keep track of this over there and might find a suitable approach.

[digizen]

@zewa666 Yup, I'll take care of it.