Closed cvan closed 8 years ago
:+1: Looks good to me, thanks for doing this!
Hmm, but do we no longer run the clobber
task? If that's the case that could potentially leave the app in a bad state?
Hmm, but do we no longer run the clobber task? If that's the case that could potentially leave the app in a bad state?
I don't see how. it might just leave stale files around.
but it won't affect it, as long as things aren't referencing it. and, fwiw, I filed #239 since gulp.watch
already doesn't get triggered when you delete a file.
anyway, clobber
will get run when you restart the app (or restart gulp
).
I'm going to merge. we should do #239 as an optimisation.
if anyone sees anything funky, file and issue and I'll investigate ASAP.
thanks!
benchmarks
2.33 s
15 ms
2.31 s
2.22 s
2.23 s
182 s
index.html
2.2 s
18 ms
view full benchmarks + gulp output
unsurprisingly, the slowest things are
babelify
(which runs Browserify with the Babel transform) andlint
(which runs eslint).Babel and Browserify are aware of the optimisations to be made: https://github.com/babel/babel/issues/1486 https://github.com/substack/node-browserify/issues/1208
locally, I tried upgrading all of our related dependencies and it brought the JS from
2.22 s
to only2.14 s
. so, we’ll just have to wait it out and hope that the transpiling stuff gets faster. moving from browserify to webpack is another option, but I’d really rather not.