4 ms·

How did you do one file at a time? Enabling it with a different extension e.g. script.es6 or similar? Did it live side by side with existing code? Were your w

How did you do one file at a time? Enabling it with a different extension e.g. script.es6 or similar? Did it live side by side with existing code? Were your watchers efficient or did it slow down over time the more you added? Looking to do this on a large JS code base soon. Thanks for your input, Josh

woah 11y ago
Js updates are backwards compatible
joshstrange 11y ago
Running non-converted files through babel is not an issue, they will just come out looking the exact same. That said we have a high number of JS files (that I am slowly pruning down) so it was a worry (time-wise it takes ~30 sec to transpile all our JS) to run them all through babel. I considered trying to add a: "use babel"; at the top of files that should be transpiled but I couldn't find a good "gulp way" to check for that. I also considered using a "filename.es6.js" structure but following file renames in SVN is a bitch and a half (not my only reason) so I didn't want to have to change those all back when es6 was widespread enough to use directly. I settled on running them all though so our "gulp build" takes 30 seconds or so but for our "gulp watch" (which starts off by building everything) I implemented caching so that only changed files had to be re-transpiled before getting concated into our "app.js" file. With this change it takes <1sec to transpile changed JS. Since our JS dev's use "gulp watch" everything works out quite nice so that they can edit a file and reload their browser to see the change immediately (30 sec times would have killed babel in it's crib for us and I assume most other places). For caching we used the gulp-cached [0] plugin. It's important to note that if you plan on concat-ing your files that you are caching then you will also need to use gulp-remember [1] which re-introduces cached files into your file stream after the intensive parts of are done so for example: var customJSStream = gulp.src('webroot/source/js/**/*.js')) .pipe(cache('app-custom-js')) .pipe(babel()) .pipe(remember('app-custom-js')) ... (NOTE: I've left out stuff from our gulpfile and simplified it for display here) We then combine that stream with 2 others and concat them all together but that's not important for this example. Let me know if you have any other questions! [0] https://www.npmjs.com/package/gulp-cached https://www.npmjs.com/package/gulp-cached [1] https://www.npmjs.com/package/gulp-remember https://www.npmjs.com/package/gulp-remember
- tracker1 11y ago
  If you break up your application into separate npm modules, each module's transpile time can be reduced quite a bit to where you're unlikely to even notice.
  - joshstrange 11y ago
    I have no doubt of that, this is for all front-end code ATM (we don't used node except for gulp). It was hard enough to move us to what we are doing now it will be some time before we get nice npm modules :(. I am looking into the options for front-end modules (CommonJS and friends) because I would like to break our stuff up a little better. It's leaps and bounds over what we started with (separation of interests-wise) but I have to be careful not to push the envelope too far and have the other devs throw up their hands and give up. Gulp was a HUGE step and it hasn't even been a full year on that yet. Bower was pretty hard as well but the team seems to have gotten over that now.
    - tracker1 11y ago
      It's probably easiest to start with any 3rd party modules already in npm.. jquery & plugins etc... from there it gets easier... assuming you're requiring in your classes and exporting already.
- drinchev 11y ago
  I would suggest adding FrontMatter [1], which will try to read a so-called YAML-header from the file, which is ignored later by gulp. You can combine it with gulp-if, to isolate those files that need compilation. 1: https://www.npmjs.com/package/gulp-front-matter https://www.npmjs.com/package/gulp-front-matter
  - joshstrange 11y ago
    Oooo, I haven't seem that, that's pretty neat. If our current method doesn't end up working out (been doing well for over a month now) and/or I get the time to address the initial 30 sec build then I will look into this. My only concern is our sourcemaps which have been.... finicky... at best. They work fine now that I've got them working but I had a hard time getting them to correctly spit everything out. Adding YAML to the files the yanking it out may have adverse effects on our sourcemaps but the only way to know is to try it out! Thanks for the suggestion, I've got it bookmarked now!
danieldisu 11y ago
It's a good start to switch the extension name so you now in which files you can use es6... But as the other commenter said, all es5 JS is valid es6 JS...
- joshstrange 11y ago
  I'd shy away from this personally due to SVN issues with renames/moves (yes, yes git is better, I'm working on convincing the people who control that decision) along with the fact that you will have to do it all over again in a year or two unless you plan on always naming your JS that way. My biggest reason for even trying not to run them all through the transpiler was speed.
_greim_ 11y ago
> How did you do one file at a time? I suspect they just flipped a switch causing all files to be run through the transpiler, regardless of filename extension or anything. However at the time the switch was flipped, none of those files actually contained any ES6-specific syntax, so the transpiler was mainly just passing code through unchanged, even though it technically is transpiling everything. Now they're simply going through the code and swapping in ES6 syntax here and there. It all works because 6 is a superset of 5.

woah 11y ago

Js updates are backwards compatible

joshstrange 11y ago

Running non-converted files through babel is not an issue, they will just come out looking the exact same. That said we have a high number of JS files (that I am slowly pruning down) so it was a worry (time-wise it takes ~30 sec to transpile all our JS) to run them all through babel. I considered trying to add a: "use babel"; at the top of files that should be transpiled but I couldn't find a good "gulp way" to check for that. I also considered using a "filename.es6.js" structure but following file renames in SVN is a bitch and a half (not my only reason) so I didn't want to have to change those all back when es6 was widespread enough to use directly. I settled on running them all though so our "gulp build" takes 30 seconds or so but for our "gulp watch" (which starts off by building everything) I implemented caching so that only changed files had to be re-transpiled before getting concated into our "app.js" file. With this change it takes <1sec to transpile changed JS. Since our JS dev's use "gulp watch" everything works out quite nice so that they can edit a file and reload their browser to see the change immediately (30 sec times would have killed babel in it's crib for us and I assume most other places). For caching we used the gulp-cached [0] plugin. It's important to note that if you plan on concat-ing your files that you are caching then you will also need to use gulp-remember [1] which re-introduces cached files into your file stream after the intensive parts of are done so for example: var customJSStream = gulp.src('webroot/source/js/**/*.js')) .pipe(cache('app-custom-js')) .pipe(babel()) .pipe(remember('app-custom-js')) ... (NOTE: I've left out stuff from our gulpfile and simplified it for display here) We then combine that stream with 2 others and concat them all together but that's not important for this example. Let me know if you have any other questions! [0] https://www.npmjs.com/package/gulp-cached https://www.npmjs.com/package/gulp-cached [1] https://www.npmjs.com/package/gulp-remember https://www.npmjs.com/package/gulp-remember

tracker1 11y ago
If you break up your application into separate npm modules, each module's transpile time can be reduced quite a bit to where you're unlikely to even notice.
- joshstrange 11y ago
  I have no doubt of that, this is for all front-end code ATM (we don't used node except for gulp). It was hard enough to move us to what we are doing now it will be some time before we get nice npm modules :(. I am looking into the options for front-end modules (CommonJS and friends) because I would like to break our stuff up a little better. It's leaps and bounds over what we started with (separation of interests-wise) but I have to be careful not to push the envelope too far and have the other devs throw up their hands and give up. Gulp was a HUGE step and it hasn't even been a full year on that yet. Bower was pretty hard as well but the team seems to have gotten over that now.
  - tracker1 11y ago
    It's probably easiest to start with any 3rd party modules already in npm.. jquery & plugins etc... from there it gets easier... assuming you're requiring in your classes and exporting already.
drinchev 11y ago
I would suggest adding FrontMatter [1], which will try to read a so-called YAML-header from the file, which is ignored later by gulp. You can combine it with gulp-if, to isolate those files that need compilation. 1: https://www.npmjs.com/package/gulp-front-matter https://www.npmjs.com/package/gulp-front-matter
- joshstrange 11y ago
  Oooo, I haven't seem that, that's pretty neat. If our current method doesn't end up working out (been doing well for over a month now) and/or I get the time to address the initial 30 sec build then I will look into this. My only concern is our sourcemaps which have been.... finicky... at best. They work fine now that I've got them working but I had a hard time getting them to correctly spit everything out. Adding YAML to the files the yanking it out may have adverse effects on our sourcemaps but the only way to know is to try it out! Thanks for the suggestion, I've got it bookmarked now!

danieldisu 11y ago

It's a good start to switch the extension name so you now in which files you can use es6... But as the other commenter said, all es5 JS is valid es6 JS...

joshstrange 11y ago
I'd shy away from this personally due to SVN issues with renames/moves (yes, yes git is better, I'm working on convincing the people who control that decision) along with the fact that you will have to do it all over again in a year or two unless you plan on always naming your JS that way. My biggest reason for even trying not to run them all through the transpiler was speed.

_greim_ 11y ago

> How did you do one file at a time? I suspect they just flipped a switch causing all files to be run through the transpiler, regardless of filename extension or anything. However at the time the switch was flipped, none of those files actually contained any ES6-specific syntax, so the transpiler was mainly just passing code through unchanged, even though it technically is transpiling everything. Now they're simply going through the code and swapping in ES6 syntax here and there. It all works because 6 is a superset of 5.