Front-end development toolkit deel 1:Package Management

Front-end development heeft de afgelopen jaren een enorme vlucht genomen. Er zijn veel browsers bijgekomen, er moet een wildgroei aan apparaten worden ondersteund en nieuwe technieken volgen elkaar in razend tempo op. Om dit bij te houden kom je er als front-end developer niet meer mee weg om geen tools in te zetten die jouw workflow optimaliseren. In deze blog serie beschrijf ik welke tools we bij Insyde gebruiken. Ik ga in op hoe en waarom we dat doen en laat ik je zien hoe jij er zelf mee aan de slag kan.

Samenvattend

Kort samengevat zijn de doelen die in deze blogserie aan bod komen als volgt:

  • Package managers gebruiken voor het scheiden en ordenen van afhankelijkheden van (externe) assets (script, plaatjes, styling etc.).
  • Een task runner (Gulp) gebruiken om geestdodende taken te automatiseren.
  • Gulp plugins gebruiken om code en assets te controleren en het resultaat te optimaliseren voor livegang.

Denk je hier wat aan te hebben, lees dan vooral verder!

Package management

Een website bestaat tegenwoordig uit een heleboel elementen: frameworks, afbeeldingen, styling, scripts en lettertypen. Door een package manager te gebruiken ben je in staat om je afhankelijkheden van deze (externe) bronnen op orde te houden.

Onze keuze voor het beheren van deze front-end packages voor onze op PHP-gebaseerde websites is gevallen op Bower. Tegenwoordig kun je het ook met NPM (Node Package Manager) doen, maar wij vinden de scheiding van front-end packages en Node modules erg fijn, kwestie van smaak. Met Bower kan je packages (zoals bijvoorbeeld jQuery plugins) downloaden, installeren en updaten. Zie http://bower.io/search/ voor een uitgebreide lijst van de beschikbare packages.

Je kent het wel, je wil een jQuery plugin installeren. Je gaat naar de website van die plugin, download een zip-bestand en dit pakt dit handmatig uit op de juiste locatie binnen je site. Dat is verleden tijd. Tegenwoordig is het zo simpel als het uitvoeren van een enkel commando op de command line.

$ bower install naamvandeplugin --save

Voordat je dit kan doen moet je Bower installeren, en laat dat nou net zelf ook een package zijn! Snap je het nog? 

Project layout

Even een zijspoor. Voordat je echt aan de slag gaat, is het belangrijk dat je project een logische mappenstuctuur heeft. Onderstaand de mappenstructuur die wij hanteren. We maken hierin een scheiding tussen dingen die online gaan (/site) en bronbestanden (/src). Verder zie je nog bronmappen /bower_components en /node_modules, deze worden automatisch aangemaakt door respectievelijk Bower en NPM. In de volgende blogs komt aan bod hoe we al deze bronbestanden verwerken, samenvoegen en verplaatsen naar de /site-map.

  • bower_components
  • node_modules
  • site
    • css
    • dist
    • fonts
    • images
    • script
    • index.php
  • src
    • fonts
    • images
    • script
    • styles
  • templates
  • bower.json
  • package.json

Node.js

Bower is een Node.js package. Met Node.js kun je javascriptapplicaties op webservers draaien, maar je kunt het ook inzetten om op jouw systeem allerlei taken uit te voeren. Voor het uitvoeren van deze taken zijn duizenden packages beschikbaar die je kunt installeren via Node Package Manager (NPM), zoals Bower, Gulp, Browser-sync & Imagemin. Neem maar eens een kijkje in de uitgebreide repository: https://www.npmjs.com/

Voordat we met Bower aan de slag kunnen, moet je dus eerst Node.js installeren, dat is te downloaden via https://nodejs.org/. Als het gelukt is, moet je het volgende commando kunnen draaien:

$ node -v

Geeft dit een versienummer terug, dan is Node.js succesvol geïnstalleerd! Je beschikt nu ook al over NPM, maar dit is niet altijd de laatste versie omdat Node.js minder vaak een update krijgt dan NPM. Om te zorgen dat je de nieuwste versie van NPM draait, is het dus raadzaam deze nog een update-zwengel te geven met het volgende commando:

$ npm install npm -g

Package.json

Package.json is een configuratiebestand voor NPM waarin je kan bijhouden van welke Node modules je project gebruikmaakt. In een volgende blog slaan we hier bijvoorbeeld onze task runner in op en de plugins die we gebruiken. Je maakt het package.json bestand door in de hoofdmap van je project via de console het volgende te doen:

$ npm init

NPM stelt je een aantal vragen om meer te weten te komen over je project.

name: projectnaam
version: (1.0.0)
description: Een beschrijving van het project
entry point: (index.js) site/index.php
test command:
git repository:
keywords:
author: Jouw Naam <jouwnaam@website.nl>
license: (ISC)

Dit geeft een package.json bestand met de volgende inhoud als resultaat:

{
  "name": "projectnaam",
  "version": "1.0.0",
  "description": "Een beschrijving van het project",
  "main": "site/index.php",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Jouw Naam <jouwnaam@website.nl>",
  "license": "ISC"
}

NPM is nu klaar voor gebruik binnen je project.

Bower

Terug naar Bower. Nu we de basisbenodigdheden hebben staan kunnen we Bower globaal (-g) installeren. Door globaal te installeren kunnen andere projecten er ook gebruik van maken. Installeer dus met het volgende commando:

$ npm install bower -g

Bower.json

Om je projectspecifieke afhankelijkheden op te slaan maak je, net als voor NPM, een configuratiebestand: bower.json. In dit bestand word opgeslagen welke packages je project gebruikt en welke versies. Ook houd je hierin bij welke bestanden van de packages je uiteindelijk online wil zetten. Je maakt dit bestand door naar de hoofdmap van je project te gaan en het volgende commando uit te voeren:

$ bower init

 Bower stelt je een paar vragen om meer te weten te komen over je project:

? name projectnaam
? description Een beschrijving van het project
? main file site/index.php
? keywords
? authors Jouw Naam <jouwnaam@website.nl>
? license
? homepage
? set currently installed components as dependencies? y
? add commonly ignored files to ignore list? y
? would you like to mark this package as private which prevents it from being accidentally published to the registry? y

Dit resulteert in een bower.json bestand met de volgende inhoud:

{
  "name": "projectnaam",
  "description": "Een beschrijving van het project",
  "main": "site/index.php",
  "authors": [
    "Jouw Naam <jouwnaam@website.nl>"
  ],
  "license": "MIT",
  "homepage": "",
  "private": true,
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "test",
    "tests"
  ]
}

Bower is nu klaar voor gebruik binnen je project.

Aan de slag met packages

Eindelijk, we kunnen echt aan de slag en kunnen onze eerste Bower package installeren! Als voorbeeld nemen we de Slick carousel van Ken Wheeler. Deze willen we graag installeren in ons project. Hiervoor open je weer de console in de hoofdmap van je project. Je kan de bower repository doorzoeken met het search commando.

$ bower search slick

Hier zie je dat de Slick die wij willen gebruiken slick-carousel heet. We installeren de package met het volgende commando, waarbij de modifier --save er voor zorgt dat de afhankelijkheid ook wordt opgeslagen in ons bower.json bestand. Met #1.5.9 geven we aan dat we specifieke versie 1.5.9 willen installeren. Zonder dat je een versienummer meegeeft, krijg je automatisch de laatste versie.

$ bower install slick-carousel#1.5.9 --save

Als je nu in de /bower_components map kijkt zie je dat jQuery ook automatisch is geïnstalleerd. Dat is namelijk een afhankelijkheid van Slick carousel. Deze afhankelijkheid van jQuery is aangegeven in het bower.json bestand van Slick carousel. Bower packages houden hun eigen afhankelijkheden dus ook bij in hun eigen bower.json bestand. Onze eigen bower.json file is op de achtergrond geüpdatet:

"dependencies": {
    "slick-carousel": "1.5.9"
}

Als je een package wil updaten en je hebt het versienummer niet vastgezet, dan kan je dat doen met:

$ bower update slick-carousel --save

Een package verwijderen gaat logischerwijs als volgt:

$ bower uninstall slick-carousel --save

Bower Main files

In onze bower.json file hebben we tijdens de initialisatie al aangegeven wat de main file van ons project is, namelijk site/index.php. Bower packages geven zo de belangrijke bestanden aan, vaak zijn dit de bestanden die je wil gebruiken binnen je project. Zo staat in de main eigenschap die we vinden in bower.json van de eerder geïnstalleerde Slick carousel het volgende:

"main": [
    "slick/slick.js",
    "slick/slick.css",
    "slick/slick.less",
    "slick/slick.scss"
],

Met de SCSS en LESS files gaan we nu niks doen, dus die willen we liever niet in ons project. Omdat we tevens het bijgeleverde thema van Slick willen gebruiken is deze lijst dus niet compleet, we moeten de main eigenschap dus overschrijven. Gelukkig kan dat! In je eigen bower.json file overschrijf je voor de Slick package de main eigenschap als volgt:

{
  "name": "projectnaam",
  "authors": [
    "Jouw Naam <jouwnaam@website.nl>"
  ],
  "description": "Een beschrijving van het project",
  "main": "site/index.php",
  "license": "MIT",
  "homepage": "",
  "private": true,
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "test",
    "tests"
  ],
  "dependencies": {
    "slick-carousel": "1.5.9"
  },
  "overrides": {
	"slick-carousel": {
      "main": [
	    "slick/slick.js",
		"slick/slick.css",
		"slick/slick-theme.css",
		"slick/ajax-loader.gif",
		"slick/fonts/slick.eot",
		"slick/fonts/slick.svg",
		"slick/fonts/slick.ttf",
		"slick/fonts/slick.woff"
	  ],
	}
  },
}

Om de bestanden van Slick te gebruiken binnen onze website moeten we een volgende tool inzetten, een task runner, daarover meer in het volgende deel!


Meer informatie

Wil je meer informatie over bovenstaande onderwerpen, lees dan naar hartenlust verder op de volgende sites:

Geschreven door Maarten van Spil

Front-End Developer & UX Designer

Blijf up-to-date en ontvang updates in je mailbox

Lees ook deze interessante blogs

Is mijn website mobielvriendelijk?

Eerder schreven we al over het verchil tussen een mobiele website, een responsive website en een mobiele app. In dit artikel zoomen we wat verder in wat mobielvriendelijk eigenlijk is, waarom het belangrijk is en waar je op moet letten. Oké. Laten we van start gaan!

Mobiele site vs responsive website vs app

Eerder schreven we al over het belang van mobiel voor Google. Nu wil ik graag inzoomen op de verschillende opties om mobiele bezoekers te bedienen met een mooie online ervaring. Zoals de titel van het artikel al aangeeft zijn er drie smaken: Mobiele website, Responsive Website en IOS/Android (native) App. Ik start met het bespreken van de verschillende opties en  ik zal afsluiten met een conclusie hoe wij kijken naar welke oplossing je wanneer nodig hebt. 

Front-end development toolkit deel 3: Gulp plugins

Gulp op zich is al geweldig, maar met een breed scala aan plugins kun je jouw assets pipeline en front-end workflow pas echt goed optimaliseren. In het laatste deel van deze blogserie bespreek ik de belangrijkste plugins en hoe je ze samen kunt inzetten.