how to write a gulpfile using a language that requires transpilation (babel)? - gulp

I am learning gulp and practicing writing gulpfile.js. gulp is for transforming js etc files. however, if I want to write gulpfile.js using es6, I may need to involve babel. I notice the following doc: https://gulpjs.com/docs/en/getting-started/javascript-and-gulpfiles#transpilation
but I still am still confused. why I rename this file and how does it compile 'import' syntax? "gulpfile transpilation documentation" is broken. please help
Thanks

Related

how Babel search for a babel.config.json file?

when i read the babel config file document that Babel will automatically search for a babel.config.json file, im curious about how babel find the babel.config.json and apply it, can somebody show me the code, thanks

Webpack compiling ES6 into module

I am trying to compile ES6 to a file using Webpack and can't figure out why the code is not usable as it is.
Side note : This is meant to be a plugin for VueJS
I start with a simple file that exports a single function such as
exports.install = () => {
...
}
Webpack uses babel-loader and babel-preset-es2015 to compile it.
You may find webpack config, source and compiled files in this gist.
My problem is the result is not "requirable" in my Vue app... It has some weird stuff around the core needed exports.install statement. When I remove all this stuff and leave just exports.install = ... it is OK, otherwise I just don't get anything out of it.
I am using it in another app built with webpack, through an import statement.
Without an output.libraryTarget option, webpack will generate a bundle you can include via a <script> tag, but not import. I think this is what you're seeing.
If you want to import (or require) the result of your webpack build, you should set libraryTarget to commonjs2
output: {
filename: 'index.js',
libraryTarget: "commonjs2"
},
With this libraryTarget configuration, the webpack output will look like module.exports = /* ... the "weird stuff" */, so when you import it, you'll get the exported function you expect.
If all you're doing is compiling a single file or set of files that will be imported in another webpack build, you might consider not using webpack at all, and instead using the Babel CLI directly. In your Gist, you're not getting anything from webpack other than wrapping your module in some extra webpack bootstrap code.

Gulp: How to setup an automated src & dist folder structure?

Is there a best practice or common task(s) that people use to separate their source code and minified code? I don't want to have to re-minify and concatenate a file manually every time I edit it in the src/ directory.
Apologies if this is an extremely obvious answer, but I cannot seem to find any good Gulp tutorials on folder structure dependency.
Thanks in advance.
One common practice is to have a dev task that runs gulp-watch when you're working on something. This task (probably) shouldn't minify or run any other production type tasks. Then when you're ready to deploy you run your prod task which will minify and add cache busting, whatever you need (without gulp-watch).
In terms of folder structure you can have a /src and /dest directory if you'd like. It keeps things clean in your src directory and you can clean/delete the entire contents of the /dest directory because you know those are all generated files.

Gulp with WebPack. Which should be building my coffee/jade etc.?

I have a pre-existing project that is currently using gulp.
The key libraries/frameworks/languages are:
MongoDB - Mongoose
AngularJS - With ui-router, also using ngClassify
ExpressJS - With Passport
NodeJS
Jade
Coffeescript
Sass - '.sass' format
JPG/PNG's
Currently everything is watched using live reload, minified using uglify and gzipped. My angular html view/directive snippets are sent into a template cache js file. Even the images are minified using image min.
The single page app is very modular by design, there are multiple 'pages' to the app, each page has a specific use (Take the profile page for example), using ui-route to nest views. Not all users will use each page. Hence why I am choosing to move towards WebPack with each 'page' being a module. The goal for this application is to be as reactive as possible. With potential mild load times when switching which page/module they are on.
My current project structure has a src and dist directory each with a server and client folder. the list directory can of course be safely deleted with every build. I currently have no raw js files or raw html (aside from the gulpfile.js that just requires my gulpfile.coffee), everything gets preprocessed by gulp and thats it.
So here are my questions:
Do I replace most of my gulpfile with webpack, and let webpack process everything (Whats the advantage of this). Or do I create an intermediary folder (The gulp output), then run webpack on that folder (just dealing with the minified js/css/html files). Basically, knowing what my libraries/frameworks are, and my situation, how would you structure the build process?
Can you use an ngClassify app.coffee file as an entry point? Or does it have to be compiled first. (If you can, how?)
You can certainly use Gulp to trigger your Webpack build and manage other tasks you may have however the idea of Webpack is that it is your entire build, you no longer need Gulp tasks to 'minify, 'concatenate' and 'imagemin' files etc as Webpack does all this for you by using Plugins and Loaders.
You will have to run Webpack on the project source, not an already minified bundle created by your custom Gulp build.
The angular questions I don't have an answer to I'm afraid :)

Bower and Grunt workflow

I just want to get an opinion on my workflow. I am aware of Yeoman and have on purpose decided not to use it. My workflow goes like this:
Run bower install to install all project assets dependencies.
Run grunt which copies all js files from the bower components folder to a new js folder and all css files to a new css folder.
Further use grunt task to concatenate and minify all js and css files from the new folders and put them in a dist folder.
Refer to the final minified css and js in dist folder from HTML.
One thing i certainly don't want to do in my grunt task is to perform dependency specific task e.g. grab all js file from bootstrap folder into the new js folder, then grab all js file from prettyphoto folder into the new js folder. I want the grunt task to be as generic as possible so that i can use the same gruntfile in any project no matter what the bower dependencies might look like. The reason is if i should spend all those time writing my gruntfile for each project, why would i not just grab the source codes for all the dependencies in conventional way.
So there is a grunt-contrib-copy plugin to copy files from one place to another which i use to grab all js files from inside the bower's components folder. The problem is most of the bower components come with regular js and minified version of it. So, i am copying both of them and concatenating and uglifying them. So duplicate code!
Does my workflow makes sense? Is so, how can I get rid of the problem I mentioned in the paragraph above?
If I'm understanding correctly, you should take a look at grunt-usemin. You can wrap your js tags in <!-- build:js js/foo.js -->. The useminPrepare task that's included in the package will cycle through any scripts (or css, or images, etc.) that are there and dynamically add them to the concat or uglify task.
The one downside I've found is that the usemin task is fairly slow but hopefully if this pull request is implemented, things will get much, much faster.