Posts Tagged ‘npm’

Modern Web Development – Part one

Wednesday, February 17th, 2016

Since April last year, I’ve been plunging again in the world of Web development.. and what fun it has been! In this series of posts, I’m going to summarize the stuff I’ve done last year in order to hop back on the train and I’ll describe what I’ve learned along the way.

At the time, I published two blog posts, which were my way of condensing my vision for an important project at work aiming to modernize the way we create Web applications by going towards a client-side architecture combined with RESTful Web Services on the back-end.

When I started looking back at how the Web platform had evolved during the 2012-2015 period, the main things I had on my mind were:

  • mobile first & responsive web design
  • client side Web application architecture (which I personally consider to be the part of Web 3.0 — seriously, why not?)
  • the new specs that had reached broad support in modern Web browsers and were gaining a lot of traction
  • the offline first idea that these specs made more realistic

I wanted to learn more about AngularJS, node.js, npm and sass but that was about it. I remember that at first, I had no precise idea yet about the build tool and the build steps that I wanted/needed… I hadn’t even heard about ES6 yet!

Since then, I’ve learned a ton about ES2015, TypeScript, module systems, module loaders, JS frameworks & the tooling around, front-end state management solutions, front-end build systems, project boilerplates, css style guides, quality assurance for front-end apps, unit & e2e testing libraries, … and the integration of it all…

The funny thing is that… I failed to deliver.

Initially, my personal goal was to create a responsive client-side Web app exploiting the RESTful API of my WordPress installation to replace my current theme, but I changed my mind along the way… So far, my site hasn’t changed one bit. I did improve some things though, but that was more around security than anything else.

So what made me change my mind and where did I spend my time?

At first, I was concentrated on the task at hand and I looked at how the HTML5 boilerplate had evolved as I knew that it was one of the best starting points around for creating modern Web apps. My idea was simple: use HTML5 boilerplate or InitializR to get ModernizR… and add some good old script tags… :p

I started with HTML5 boilerplate, but shortly after, I stumbled upon Web Starter Kit which was fresh out of Google’s oven, was based on HTML5 boilerplate and had some really cool features.

It came out of the box with a nice build which included support for JSCS (JS code style), JSHint (JS code quality), autoprefixing, BrowserSync (if you don’t know that one, DO check it out!), sass and ES6 (that was still the name at that point) with the help of Babel, …

 I really liked their setup and decided to use it as basis for my project; and that’s where my trajectory deviated :)

Given that I’m quite curious, I spent a while deconstructing Web Starter Kit’s build so that I could really understand what made it tick. That made me discover npm, gulp and the whole ecosystem of gulp plugins.

I really enjoyed doing so as it has helped me better grasp the necessary build steps for modern Web apps:

  • transpile code (ts->js, sass->css, …)
  • check quality
  • check style
  • create a production build (bundle, minify, mangle, …)
  • execute unit tests
  • execute end to end tests
  • …

At that moment, I was happy with the build as it stood so I continued to focus on developing my app. I took a good look at what ES6 was, what it meant for JavaScript, its ecosystem and how Babel helped (was it still called 6to5 then?). Learning about ES6 features took me a long while and I’m still far from done, but it was well worth it. ES2015 is such an huuuuuuuuuuuge step forward for the language.

I also took a glance at Angular 2 which was still in alpha state. It looked interesting but I believed that it would never be ready in time for our project at work (and it wasn’t). Still, I did spend a few days toying around with the alpha just to get to understand the basic principles.. and I must say that I really really loved what I saw!

That quick research spike also made me discover TypeScript.

Having a strong Java & OO background, TypeScript (TS) directly got me excited. I’m a strong believer in strong (heh) typing, and the fact that TS already supported many ES6 features that weren’t natively supported by Web browsers yet was very appealing to me.

Moreover, having dozens of Java developers in our development teams at work, TypeScript seemed really ideal for us as it supports many features and idioms that our developers are very familiar with (classes, interfaces, generics, strong typing, decorators, …).

If you want to learn more about TypeScript, I definitely recommend the Typescript Deep Dive.

At that point, tsconfig.json wasn’t there yet and the most evident choice to integrate the necessary build step was gulp, as advertised by Dan Walhin’s excellent blog post. If I had read more about npm I might have gone a completely different path (i.e., used npm scripts only).. ^^.

At that point, I had to deviate from what Web Starter Kit offered me in order to add build tasks for TypeScript, tslint, etc. Fiddling with the build made me realize that it was quite brittle, so I refactored it quite a lot and tried to improve things (e.g., separate the build tasks in different files, extract the configuration settings, ensure that it would not break the build on each error, etc). I remember that I wanted to contribute back to Web Starter Kit but realized too late that I had made too many changes at once for them to be able to integrate easily (silly me, bummer).

I went pretty far with actually as at some point, I was using TypeScript to output ES6 code that I then sent through Babel, just so that I could use async/await and other things that TypeScript wasn’t able to transpile to ES5… :)

The exercise helped me see how “immature” and “fragile” the whole JavaScript ecosystem was. What I mean by that is that there seems to be only moving parts and each of those parts don’t necessarily keep happy with each other. Not only do too few people really understand what semver actually means and respect it, but everything that shines bright gets replaced faster than the speed of light :)

As a technologist, I love the pace it imposes for the fun and innovation it brings to the table, but it’s also frustrating for many reasons and (should be) quite scary for enterprises (to some degree). People talk about JavaScript fatigue, which is quite a fun way to put it and I can certainly understand the idea now.

One example that I thought a lot about is the fact that each and every front-end project seems to have its own build chain and build configuration that lives within the project, in complete isolation and has to be maintained.

Of course each and every project has its specificities so there really can’t be ONE rigid & reusable solution to rule them all, but the idea of duplicating so much effort needlessly across a whole community of developers violates the DRY principle as much as anything ever could.

Just try and imagine how many people must have used some Yeoman generator to scaffold projects, which now all have separate builds with tasks that all do the same things but are all defined 20.000 times in a gazillion different ways using variable and unreliable dependency versions… :)

When you scaffold a project using a generator, you end up with a snapshot of the template and of the build provided by the generator at that point in time and then it’s up to you to keep your version up to date and to integrate all improvements and bug fixes, assuming you have time to follow that… you poor thing!

Being part of a core software development team at work, my focus is most often on finding reusable solutions to common problems, limiting effort duplication and what not and thus, the front-end universe’s situation seems quite sad in that regard.

Another point that struck me was how limited the main package management solution was. npm is nice and all, but not being able to define some parent/generic/reusable configuration (e.g., like parent pom files in Maven) is kind of surprising. Again, the DRY principle probably corresponds to DO Repeat Yourself in the frontend universe. I’m sure that front-end experts will tell me that you can work around all that in countless ways, but that’s exactly the issue: I shouldn’t have to invent my solution for a general issue people should be concerned about.

To conclude on a positive note though, I do believe that all the tooling DOES bring added value because it makes it possible to manage dependencies correctly, define build steps which execute tests, generate coverage reports (e.g., using Istanbul), generate production builds etc.

This piece is getting a bit long, so I’ll continue my little story in part two!

 

Tags: , , , , , , , , , , , , , , , , ,
Posted in JavaScript, Software Development, Uncategorized, Web Development | Comments Off on Modern Web Development – Part one


Installing node and npm on Ubutun 15+

Friday, December 18th, 2015

In case you would want to use one of my recent projects (e.g., ModernWebDevGenerator or ModernWebDevBuild) on Ubuntu (or any other OS btw), you’ll need nodejs and npm.

If you’re using ubuntu and go the usual way (i.e., sudo apt-get install…) then you’re in for a bad surprise; you’ll get node 0.1x.y and also a very old npm release.

Actually, the best way to get nodejs and npm on Ubuntu is to use the node version manager (nvm).

nvm can be used to install and keep multiple versions of node in parallel, which is very useful, especially when you have to test your node-based project on multiple versions.

The installation is very straightforward:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.29.0/install.sh | bash

After that, close and reopen your terminal. You now have ‘nvm’ at your disposal.

nvm install 4.0
nvm install 5.0
nvm use 5.0

Just with the above, you get two versions of node (along with npm) installed. As you can see, you can use ‘nvm use’ to change the active version easily.

That’s it!

Tags: , , , , ,
Posted in IT, JavaScript, Software Development, Uncategorized, Web Development | No Comments »


My current global npm packages

Sunday, July 26th, 2015
If you’re familiar with nodejs & npm you already know this (just skip this part), but newcomers should realize that npm packages can not only be installed locally in a project’s folder, but also globally. Packages that are installed globally are.. globally accessible, which is really cool because using npm you can install many CLI tools to streamline your workflow and boost your productivity.
 
To install a package globally, you simply need to use the –global (-g) flag. For example:
 
npm install --global gulp
Note that you can customize where npm stores globally installed packages by creating a .npmrc file in your home folder and adding the following to it:

 
prefix="/path/to/your/global/npm/packages"
You then simply have to add that same path to your system’s path to get all the tools available at your fingertips.
 
Here’s a small list of npm packages that I currently install globally
  • gulp: Streaming build system for the web!
  • babel: JS transpiler. Because we all want ES2015/2016/20xy right now!
  • jspm: JavaScript package manager: one package manager to rule them all. Let’s just forget about npm vs bower vs git vs whatever, just use jspm and be done with it
  • typescript: Ahhh TypeScript, worth explaining in its own post because strongly typed JS is the future and the future is now
  • tsd: TypeScript type definitions downloader. Because TypeScript without type definitions isn’t very useful
  • brower-sync: Easy to use web server that will make your developer life easier: automatically refresh/sync across all connected devices
  • http-server: Minimalist web server (zero-configuration). Using this you can easily serve local content
  • sass: CSS preprocessor (also deserves its own post). Until I free up some time to learn more about PostCSS, I’ll continue to use this
  • node-sass: SASS without Ruby, weeee
  • yo: CLI to run Yeoman generators
  • slush: Another scaffolding CLI (based on Gulp)
  • caniuse-cmd: CLI to easily check browser compatibility of certain features using data from caniuse.com
  • reveal-md: Quickly generate a reveal.js presentation from markdown content
  • superstatic: Nice web server for SPAs
  • bower: Package manager for the web. I install it for older projects
  • grunt: Task runner for the web. Same as above
  • node-inspector: Blink-based debugger for NodeJS apps
  • node-debug: Wrapper for node-inspector
  • speed-test: Test the speed of your Internet connection
  • semantic-release-cli: Ease your life when creating new releases
  • npm-bump: Another alternative for easy releases
  • center-code: a simple way to show file contents in the console
  • npm-check: check for outdated dependencies
  • rimraf: easily delete files (even paths that are too long on Windows)

Tags: , , , , ,
Posted in IT, JavaScript, Web Development | Comments Off on My current global npm packages


Quick NPM tip and a little rant about node-gyp

Wednesday, July 1st, 2015

Before I start explaining why I’m writing this, here’s my NPM tip of the day: if you encounter errors pertaining to node-gyp “rebuild”, while trying to install an NPM package, then before wasting precious hours of your life, just try to install using the –no-optional flag; if you’re in luck, that’ll just work (as it did for me in most cases).

Now what the heck is node-gyp? That’s a fair question to ask. As they put it in their readme it’s a “cross-platform command-line tool written in Node.js for compiling native addon modules for Node.js … and takes away the pain of dealing with various differences in build platforms”.

Well the way I now see it, it might just do what they say.. for people who need/care about that, but for the rest of the world and especially people like me who just want to install an npm package and get on with their life.. it’s just trouble and needless time waste.

Sometimes when you try to install an NPM package, there will be some dependency in the tree that requires to be built specifically for your platform and at that point, node-gyp (which is one of the dependencies of NPM itself) might come into play. The issue is that to be able to do its job, node-gyp has some prereqs that vary from OS to OS and those prereqs are not part of node/NPM (you’ll soon understand why :p). If you’re one of the good guys and use Linux (you should… and I should too but can’t) then you’ll be alright: python + make will make your day (you’ll also be fine with OSX).

Unfortunately, if you’re a sad panda working on a Windows box just like me, then tough luck!

Here’s a little overview of the ‘light/small’ requirements that node-gyp has on Windows 8+:

  • Python (2.7.x and NOT 3.x+): ok just with this one I already dislike node-gyp
  • Microsoft Visual Studio C++ 2013: ok, now I hate it. Do I really need 7GB just to get an npm dependency on my machine? Wtf (pre-compiled binaries FTW, if I wanted to compile everything myself on my machine, I’d still be using gentoo..)
  • and last but not least, for 64-bit builds… Windows SDK: are you kidding me?!!

Assuming that you’re motivated, then you’ll go ahead and install these.. try again and… still get the same error?! Gee… Well the thing is that quite some people have encountered this problem and have hopped through all kinds of hoops to finally get it to work. Some have had success by uninstalling all Visual C++ redistributable packages (any gamers around here?), reinstalling node-gyp’s dependencies in a specific order, adding environment variables and whatnot..

In my case I was pretty happy to discover that in all cases, the dependencies that needed node-gyp were optional (e.g., for babel, browserify and some others), so simply avoiding them was fine. If you really do need node-gyp to work then I pity you and your disk space ^^. Just take a look at some of these links and may the force be with you.

What also sucks is that npm install rolls back on error even for optional dependencies although it’s not supposed to..

Tags: , , , ,
Posted in IT, JavaScript, Software Development | 3 Comments »


Time for some Web dev

Tuesday, April 14th, 2015

Back on 2009 I wanted to hop onto the blogging train again and created this blog. At the time, I thought that it would be a shame to use an existing WordPress theme so I’ve decided design and implement my own.

My main focus was on implementing a complete WordPress theme, thus understanding and leveraging the PHP WordPress API; I’ve also had tons of fun fooling around with jQuery to add some fanciness bits (tooltips, rounded corners, animations, effects on the images, form validation …). My goal with the blog was also to create a nice place for exposing a few pictures of my own so I’ve spent some time integrating a Lightbox (which is kind of broken now).

For the design, I’ve used the trendy CSS framework of those days: Blueprint — which seems to have been abandoned later that year :). Blueprint was like 960, it provided a nice grid system to make it easier to design the UI. Combined with a CSS reset stylesheet such as Eric Meyer’s, it allowed to create nice designs with good browser compatibility. These CSS grid systems had fixed sizes and often came with PSD files to kickstart the design work in Photoshop, making it all pretty straightforward :)

I hadn’t really considered mobiles devices during development (the big shift didn’t occur yet); moreover, CSS 3 media queries weren’t really production ready at that point and Responsive Web design was yet to go mainstream.

In the end I was quite satisfied with the result, knowing that I’m no designer to start with.

I’m still pretty happy with the theme as it stands, but the fact that it lacks responsiveness is a huge pain point nowadays. The situation could be worse, but it’s still far from perfect on small and large devices. At the time I also didn’t consider accessibility at all.

For the curious among you, this theme, known as Midnight Light, is available on GitHub: https://github.com/dsebastien/midnightlight.

I’ve only felt motivated again for the Web in 2012. At that point I was going through pretty tough times at work (lots of stuff to learn, not enough time to do so and a lot of pressure to deliver) and so when I was coming home I needed to relax. Diablo 3 was perfect for me; I played like crazy and ended up putting around 1500 hours into that damn game :).

At some point I felt the need for a tool to help me optimize my playing time and that was a perfect excuse for me to get my hands dirty with the trendy stuff of those days: HTML 5, CSS 3, WhatWG new JS APIs etc. I’ve thus created ‘D3 XP Farming‘, a pretty basic single page application created using HTML 5, CSS3, LocalStorage, ModernizR and a few hundred lines of javascript/jQuery code to put the whole thing in motion.

Thus it’s been a long while since I’ve last really developed for the Web. I’ve been thinking about creating a new theme for quite some time but kept the idea at the bottom of my todo list.

Last year, I’ve started working again as a software developer (after 3 years in the dark side of IT Ops). I’ve never really stopped reading about software development, programming languages and the evolution of the Web.

In recent months, I’ve been reading a lot about the latest W3C/What WG standards status/browser support, Web components, mobile first & offline first principles, client-side UIs, responsive design, NodeJS, NPM, browser news including stuff about some Spartan coming to finish off IE, etc etc etc.

This and related discussions at work have led me to reconsider the priority of creating a new theme for my website ;-)

Hence I hereby officially announce (haha) the creation of a new project of mine (open source as usual): Midnight Light v2.

For now the design exists only on paper but that won’t last long :)

In the upcoming posts I will talk a bit more about the current project status and my evil plans =)

Tags: , , , , , , , , , ,
Posted in Software Development, Web Development | 2 Comments »