Hammer.json Explained



Hammer is all about elegant, simple features that appeal to our community of creative people that prefer the Hammer way to the complex command line interface alternatives that exist.

We’re very protective of what goes into the main interface of our app, and the importance of this has been reinforced by the feedback we get regularly from our customers. Here’s a selection of anonymous responses from our last customer survey.

Because the product is detail oriented and design focused.

Design and features are spot on.

No bullshit.

Because of ease of use

Because this’s life saver product

The thing I love most about Hammer is the lack of bloat. It does one thing really well. Okay, maybe a few things really well – but competing products tend to be a jack of all trades, master of none.

Good Design and usability

Great design, well thought out features.

However, there’s a BUT!

But what about when I need more advanced capability? What about the lists and lists of features that we think of, that our customers think of? What happens to them? Do we just ignore them?

The answer is a resounding NO.

We have to have a process for experimenting with new features that does not result in immediate feature bloat, overly complex UI’s a product that grows to big and broad to be able to do what it does best.

That’s where the hammer.json configuration comes in.

Through this simple tool, we can enable new and experimental features within the Hammer tool, before we take the massive steps of incorporating it fully into the full app, complete with UI and any customer flow designs that that may bring.

##It’s just a file.

Hammer.json is just a file that is in the root of your Hammer project. It’s not required and won’t effect your site if you don’t have it. It’s needed if you want to use any of the advanced features.

Initially I was hesitant about bringing this into play. It’s not very “Hammer” to have a file-based config, it’s the sort of thing you’d expect from one of our command line tool competitors. But after weighing it up and discussing with our community members, I decided, what the hell. I really wanted to push some new features out without lengthy full design and development, so I just decided to give it a try.

We started simple, adding hammer.json support in 5.2.2 of the compiler. We wanted to enable Sourcemaps and Autoprefixer, optionally, within Hammer. Super useful for sites, but not something we really needed a full UI for. If you were thinking about the need for sourcemaps and autoprefixer, chances are you could handle writing a little json snippet into a file and watching it just work…

There’s a full run down of the current Advanced Configuration options available, through hammer.json in the :book: Hammer Docs

##Sourcemaps Example

Let’s take a deeper dive and see how this works in practise, between the config file and the compiler. Let’s say we have included this file on the root of our Hammer site.


  "sourcemaps": true

Our settings.rb will read this file (input_directory).


require 'json'
 module Hammer
   class Settings
     class << self
       attr_accessor :input_directory
       def sourcemaps
       def config
         return @config if @config
         config_file = input_directory + '/hammer.json'
         if File.exist?(config_file)
           @config = JSON.parse(File.read(config_file))
           { 'sourcemaps' => false }

And depending on whether is enabled (true) or not, the compiler’s sass parser will decide whether to render with or without sourcemaps.


text = if !optimized && @filename && Settings.sourcemaps

This is a very simple example, granted. But we can enable much more interesting and advanced features which we’ll continue to explore in future posts on this thread.