Improve Front-End Workflow with Grunt
•Als PPT, PDF herunterladen•
0 gefällt mir•2,371 views
Grunt is a task runner that can automate and streamline front-end development workflows. It allows developers to run repetitive tasks like minifying files, concatenating files, linting code, running tests and more. Setting up a Gruntfile to define tasks can improve efficiency by automating common project maintenance chores.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Improve Front-End Workflow with Grunt
- 1. IMPROVE YOUR FRONT-END PROJECT WORKFLOW WITH GRUNT Den Odell Head of Web Development, AKQA
Hinweis der Redaktion
- The day-to-day workflow for web developers has remained largely unchanged for a number of years as a manual process of managing assets, writing code and then testing that code in browsers. Tools have existed for checking code quality and simplifying certain tasks, but these have been run manually and, as such, tend to get forgotten. Here at AKQA, we’ve been simplifying our workflow and improving our code quality by harnessing the power of Grunt, the JavaScript-based task runner.
- - Grunt’s only dependency is Node.js - Node is a platform for running JavaScript applications on a server or command line - That means that Grunt is written entirely in JavaScript.
- - Programs, known as ‘packages’, are installed for Node using the Node Package Manager (npm) command-line tool. - Grunt is one such package, as are its tasks.
- - Before we start using Grunt itself, we need to install the Grunt Command Line Interface (CLI), which provides access to the Grunt command-line tool globally across your system. - On the command prompt, install the Grunt CLI by executing this command.
- Let’s imagine we have a small project we’re working on which contains a HTML file, an image, a JavaScript file and a CSS file, arranged within a project folder. - We’re going to add Grunt to our workflow for this project
- To enable Grunt to run against the project, we need to add two files in the project root folder: a Node package file (package.json) and a Grunt configuration file (GruntFile.js). A Node package file is a text file containing JSON-formatted project properties together with a list of node package dependencies required by the project, one of which will be Grunt in our case. -Naming this file package.json and using properties defined in the npm package file specification ( https://npmjs.org/doc/ json.html) means that the associated project can be installed together with its dependencies in a similar way to other node packages.
- Here we assign a human-friendly title for this Node package, a machine- friendly internal name and a version number according to the Semantic Versioning format - The latter two properties are essential for any Node package so make sure you don’t leave these out here.
- What’s missing now are the Node package dependencies required for our project. The most important of these to us is Grunt. - The simplest way to define a dependency and download it at the same time is to execute the following on the command line in your project directory. - Here we do that for Grunt. - The --save-dev option indicates that the package file should be updated as well as the dependency being installed locally.
- You’ll see all the files downloading within a new node_modules folder created within your project folder.
- If you open the package file again, you’ll notice the following section has been added automatically to its JSON structure. - This specifies a version number for Grunt in the project package file, so you can use different versions of Grunt for different projects.
- Now we’ve created our package file, if you have a new developer to introduce to your project, ask them to download Node, Grunt CLI as well as the project folder onto their machine. Next, tell the new team member to navigate to the project folder on the command line and type this command.
- Node will then download all the dependencies automatically according to the specific version numbers listed in the package file, and placing them within a node_modules folder for the new developer. Simple as that! - A word of advice: avoid committing this folder to source code control; let each developer download the files locally to their machine using npm and the package file.
- All Grunt tasks are Node packages, just like Grunt itself, so we need to specify each task as a dependency in the same way to make it available to our project. Let’s assume we want to use JSHint to perform static JavaScript code analysis on our project, checking for possible errors and enforcing a consistent set of coding conventions across all the JS files in our project for all developers working on it.
- This is a task perfect for Grunt, and a task called grunt-contrib-jshint exists as a Node package for us to use that does just this. - As a tip, I found a simple web search for ‘Grunt JSHint’ will locate this task for you with better certainty than the package search within the npm registry itself.
- Installing the grunt-contrib-jshint task and adding it as a dependency to your package file is as simple as executing the following command. - The package files will download and that’s our dependencies done. - We’re ready to move on to configure the other file - GruntFile.js.
- - Moving onto the Grunt configuration file, GruntFile.js - Follows the same basic structure for every project. - Use this ‘wrapper’ function, which will contain all the Grunt task settings and configuration. - module.exports property denotes that this file is in the CommonJS module format adopted by Node. Don’t worry too much about that. - However, do observe the Grunt parameter passed to the function, which is an object representing the Grunt API, containing methods and properties for working with Grunt throughout the three distinct sections of code in the rest of the file: the configuration, plug-ins and the tasks.
- Let’s skip the configuration section for the moment and jump ahead to the plug-ins section. - This is where we register the tasks we added as dependencies in our package file earlier to make them available to run in Grunt. - Add this line to the plug-ins section, which calls the API to register the JSHint npm task by name for use with Grunt.
- - According to the documentation for the JSHint plug-in, it registers a task within Grunt using the internal name jshint. This is the name we will use to refer to it from within our file. - Moving ahead once again, the tasks section of the file allows several tasks to be grouped together into a single ‘custom’ task, allowing them to be run together with a single execution of Grunt. - We register a custom task named default, which calls the JSHint task using another API call. - Extra tasks can be combined with this at a later stage by adding their internal names to the array.
- - The configuration section represents the individual settings required to tailor each task to perform the way we want in our project. - We add the code to the configuration section of the file, which configures the JSHint task using a call to the Grunt API. - We begin the configuration by defining a property named pkg into which we’ve loaded the properties from the package.json file as a JavaScript object. - This gives us access to the project’s internal name and version number, together with its other properties without having to duplicate them across both files. - We then add the configuration for the JSHint task within a property named after that task’s internal name. - This configuration consists of a set of options, matching those of JSHint itself, allowing the specific rules for code compliance to be set in one place for use across any specified file or files in the whole project. - Here we override JSHint’s strict option, enforcing all checked functions to adhere to ECMAScript 5’s strict mode - The remaining property, all, denotes the ‘target’ of the task (the files to run JSHint against). We’re choosing to check two files for compliance when the task runs: the configuration file itself and another file whose name is generated at runtime using the code delimited by the template strings <%= and %>. -This code uses the internal project name from the package file, which we stored in the pkg property to generate the filename dynamically as my-project.js. - Many Grunt tasks are built as ‘multi-tasks’, which means they can have multiple configurations, known as targets, for use in different circumstances. This adds a lot of power, and means that you could have a different set of rules for development on your local machine compared to those used before deployment to a live production server, for example.
- With our configuration in place to run JSHint across two JavaScript files, let’s run Grunt to trigger the custom task we named default. At the command prompt, execute the following command in the project root folder. Grunt actually treats this particular custom task name as the default, so we can actually run the same command without specifying the task name as an option and get the same results.
- - Grunt runs JSHint on the configuration file and the project JavaScript file, as requested, and outputs the results as follows. - Grunt ran the JSHint task on the configuration file first and, because that file failed to meet our code compliance rules, it stopped running at that point, ignoring any other files or tasks. The exact line number and character that caused Grunt to abort is shown in the output and allows us to pinpoint the code we need to change to enable Grunt to run successfully.
- Edit the configuration file and add the following line at the top of the wrapper function, enforcing ECMAScript 5 strict mode.
- Run Grunt again and it will output the following message. -In one shot we can ensure all our JavaScript files, even in a large project, adhere to the same rules, improving quality and code maintainability. We’ve essentially set up the beginnings of a frontend code build tool that, with some further configuration and extra tasks, could refuse to let us commit our code unless it passes strict code compliance rules. This can be automated to run as part of a deployment pipeline, ensuring only code that meets your strict quality control makes it through to your live site or web app.
- At AKQA, we have a Base Project Setup which includes a GruntFile and a NPM package file for allowing us to start all projects with a common foundation.
- We’re using some of the industry’s foremost tasks to increase our code quality and improve our development experience.