# gulp Published articles for gulp. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Gulp Workflow for Frontend Development Automation DevFeed: [A Gulp Workflow for Frontend Development Automation]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2017-08-15T22:25:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [Gulp](), [frontend development](), [workflow automation](), [CSS](), [JavaScript](), [make]() Tags: [automation](), [build](), [cache](), [cool](), [css](), [debugging](), [development](), [es6](), [faster](), [frontend](), [frontend-development](), [gulp](), [helps](), [here-s](), [insights](), [javascript](), [scss](), [stuff](), [tool](), [workflow]() ### AI overview A tutorial explaining why frontend workflow automation is useful and how Gulp can assemble a website's assets. It describes tasks for processing CSS and JavaScript, including SCSS compilation, browser prefixing, source maps, dependency inclusion, combining, minification, transpilation, and uglification. ### Source excerpt Gulp is a workflow automation tool that helps you build cool stuff faster; here's how to use it for frontend development. ## A Better package.json for the Frontend DevFeed: [A Better package.json for the Frontend]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2016-12-23T19:46:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [frontend development](), [Package manager](), [npm](), [Yarn](), [Gulp]() Tags: [better](), [consider](), [days](), [frontend](), [frontend-development](), [gulp](), [here-s](), [insights](), [like](), [mandatory](), [node-js](), [npm](), [npm-packages](), [package-json](), [setup](), [tools](), [webdev](), [webpack](), [workflow]() ### AI overview This article explains how to use package.json as a centralized manifest for a website's frontend packages and workflow tooling. It discusses replacing Bower with npm, and notes that Yarn can manage the same registry with deterministic installs through yarn.lock. ### Source excerpt Frontend workflow tools like gulp are almost mandatory for webdev these days; here's what I consider to be a better package.json setup ## Jekyll and Gulp workflow DevFeed: [Jekyll and Gulp workflow]() Original publisher: [Read original article]() Author: Stanko Published: 2016-02-27T00:00:00Z Content type: tutorial Language: en Sources: [Stanko Tadić]() Topics: [Gulp](), [Jekyll](), [Sass](), [JavaScript](), [Development](), [es6]() Tags: [development](), [es6](), [gulp](), [javascript](), [jekyll](), [sass](), [workflow]() ### AI overview This tutorial describes a Jekyll development workflow that uses Gulp to compile and watch SASS and JavaScript, run a local Jekyll server, proxy it through BrowserSync, and reload the browser on changes. The author notes that the setup may be outdated because they no longer use Jekyll. ### Source excerpt Please note that I'm not using Jekyll anymore, so this post might be outdated. Update, November 2017 # I don't use this setup anymore, it might be outdated, proceed with caution. Original post # As you probably know this blog is powered by Jekyll. It is a really nice platform, but it lacks a few things I'm used to during development. First one is live reload on file changes (and injecting CSS), using SASS, autoprefixer, ES6... I tried to find a boilerplate, but everything I found didn't match my needs. Usually people would run gulp tasks for SASS and JavaScript files, and on change run jekyll build, which is insanely slow. They would use BrowserSync to serve _site folder. So I did what programmers do - written my own. I quickly made usual gulp tasks: styles - to compile SASS and autoprefix it scripts - to transpile ES6 goodness, and concatenate JavaScript files serve - to start local server, watch for changes and auto reload First thing I did is that I was running jekyll serve in one terminal, and gulp serve with BrowserSync in the other. This was working decently, but I wanted to run only one command, and let the tasks do everything for me. That is where node child process comes in. import childProcess from 'child_process'; const spawn = childProcess.spawn; gulp.task('jekyll', function (){ const jekyll = spawn('jekyll', ['serve'], { stdio: 'inherit' }); }); This task spawns a child process from gulp. Nice thing is that we can start it, and gulp will kill it on exit. Now we have up and running Jekyll server, and proxy it to BrowserSync. But darn, injecting CSS files didn't really work. Server was expeting CSS file to come from /css/style.css, but browserSync.stream in gulp pipe would inject it from the _sass folder. I solved this by copying css file to the .tmp/css and adding .tmp to the serveStatic option of the BrowserSync. One thing I should mention, that I keep my SASS files in the _sass folder, and JavaScript in the _js one. Gulp watches changes on SASS/JS, and ## Using the Frontend Maven Plugin to Run Node and npm Tools in Maven Projects DevFeed: [Using the Frontend Maven Plugin to Run Node and npm Tools in Maven Projects]() Original publisher: [Read original article]() Author: espen Published: 2013-06-06T07:36:00Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Maven](), [npm](), [Java](), [Gulp](), [ci]() Tags: [ci](), [gulp](), [java](), [maven](), [npm]() ### AI overview FINN.no describes using the Frontend Maven Plugin to install Node and npm in a project folder and run Node-based front-end tools from Maven. This allowed Node build, test, and code-analysis tools to integrate with its existing Maven toolchain without requiring Node installation on every developer or CI machine. ### Source excerpt Most of FINN.no is built with Java and we've been a Java shop for 6-7 years. With the professionalization of front-end development we saw that the tools available in the Java Web Development ecosystem was preventing us from delivering rapidly and with high quality. The trend was that the tools we used weren't keeping up with the pace set by people creating tools in Node's NPM module ecosystem. When working on pet projects we could use these tools, but in our daily job we were working with second rate tools. This was a frustration for many of us, so we set out to work out how we could utilize Node without having to rewrite all our applications. In the belly of the beast that is Maven We use Maven to build and test all our applications. This includes continuous deployment and quality analysis. Our reporting tools requires projects to be built with Maven in order to work. To introduce Node-based tools for front-end tasks, we had to be able to run them from Maven. The easiest way to get started is just to use the Maven exec plugin. It allows you to run commands like on the command line. This approach worked, but there was one catch: it relied upon Node + NPM to be installed on every developer machine as well as in our CI environment. Forcing 100+ developers to install Node and keep up with versions was something which wasn't really acceptable for the rest of the organization. Enter The Maven Front-end Plugin Behold! The Frontend Maven plugin Erik Sletteberg, who started out working as a summer intern and is now working at FINN.no full time, helped solve the problem of Node having to be installed. He created the Frontend Maven Plugin which install Node+NPM in the project folder. The plugin also has tasks for running NPM, Grunt, Gulp and similar. Because of the tool we were able to use Node within a Maven web application module, which was awesome! It meant we could use build-, test and code analysis tools developed in Node and have them report into our existing tool chain