Table of Contents

What is Tincr?

Tincr does two things.

To give you a complete illustration, let’s say you’re developing a Ruby on Rails web application. You would select “Ruby on Rails” in the dropdown on the Tincr panel and then select the local directory of your rails application. Once you’ve done that, Tincr knows enough about how a RoR application is structured that if you made a change inside of Chrome Developer Tools, it would be saved to the local file equivalent. If you made a change to an application script or stylesheet using TextMate or some other tool, the change would automatically be reloaded in Chrome (possibly without even refreshing the page, depending on how you configured Tincr).


It’s recommended that you install Tincr from the Chrome web store


Tincr adds a new panel to Chrome Developer Tools.

The Tincr panel is basically a configuration screen. It consists of a dropdown to select your application type for the current page and a browse button to select your application’s root folder.

To configure Tincr, follow these steps

  1. Select an application type. This is more like a project template to make it easier for you to fine-tune your configuration. If you aren’t sure or you don’t see the type of web application you’re building in the list, select “Http Web Server”.
  2. Click the Browse button. This will open a folder select dialog. Browse to your project’s root directory
  3. Customize your configuration by setting or changing the default resource mappings for the selected project type. file url and configuration file application types can’t be customized.

Configuring Resources

You can tell Tincr exactly how you want it to behave for each individual url loaded in the browser.

After you select an application type and root folder, you are presented with a list of URL resources that are loaded for the current page. Tincr uses your application type to create initial mappings for these urls to files in your filesystem. You can view and edit these mappings under the Resources section on the Tincr panel.

Basic Resource Mapping

Resource mappings are listed out on the configuration screen and they look like this.

Advanced Mapping with Dependencies

If you select the Generated from another language checkbox. You’re given the option to Add Dependency. This option is for generated resources that may be compiled from multiple files. For example, SASS and LESS usually import partials.

If you add a dependency, the dependency is added underneath the original file mapping. You can remove the dependnency or add more.

Application types

Tincr uses the application type you specify as a template to get you started with mapping resources to the filesystem. After you select an application type and your root project directory, you can then configure Tincr further by mapping individual urls to their local files.

There are a couple of exceptions to being configurable. First, the “File url” application type is implicitly set if you use tincr from a file:// url. You can’t configure Tincr further if you’re developing against a file url. The reasoning is that it didn’t make sense to support this since it’s obvious where each url belongs in the file system.

Second, the resource customization feature is meant to replace Configuration files. Therefore, the “Configuration file” application type is being deprecated and will be removed in a later version. In the meantime, you can’t configure Tincr further if you use this application type.

File urls

If you’re developing using file:// urls, then there is no need to configure Tincr. It already knows how to associate the url to a local file. The controls on the configuration screen will be disabled.

One caveat with file urls, Tincr’s auto-reload will only detect changes underneath the inspected page’s base directory. Therefore, if your html file uses double dot syntax ‘../” to reference a script or stylesheet, changes to those files won’t be detected and auto-reloaded.

Ruby on Rails (v3.1 or higher)

For RoR applications, select the Ruby on Rails option from the dropdown. Use the browse button to select your application’s base directory. This should be the directory from which you are running “rails server”.

Tincr expects scripts to live under /app/assets/javascripts and stylesheets to live under /app/assets/stylesheets. Rails makes heavy use of pre-processing to support things like SaSS and CoffeeScript. It’s impossible to edit pre-processed files inside of Chrome Developer Tools but Tincr will auto reload changes made to these files.

Chrome extensions

You can use Tincr with unpacked Chrome extensions. To do this, use Chrome Developer Tools to inspect one of your extension pages (i.e. background.html). On the Tincr panel, select the Chrome extension project type from the Tincr dropdown, then use the browse button to select the base directory of your unpacked Chrome extension. You’ll now be able to edit your extensions scripts and stylesheets and use auto refresh for changed made externally.

Atlassian plugins

You can use Tincr in conjunction with the Atlassian Plugin SDK. You’ll need to use atlas-run or atlas-debug to run your plugin. You also need to turn off web resource batching if you want to use Tincr to save files directly from Chrome. To turn off web batching, set the “” system property to true. The easiest way to do this is to AMPS Maven plugin in your pom.xml

Configuration file

This application type is deprecated and will be removed in a later version. See Configuring Resources for accomplishing the same thing with a different application type

For stuff that doesn’t have a built-in configuration, you can specify a configuration file with some regexes that tell Tincr how to map between a file and url. Name this file “tincr.json” and put it in your root directory. You can then select the “Configuration File” option in the Project Type dropdown, then browse to your web app root directory.

Here is an example tincr.json for RoR. You would typically use the built-in Ruby on Rails configuration instead of this file. This is only for illustration purposes.

    "toFile" : [
        {"from": "/assets/(.+\\.js)",
         "to": "/app/assets/javascripts/$1"},
        {"from": "/assets/(.+\\.css)",
         "to": "/app/assets/stylesheets/$1"}
    "fromFile" : [
        {"from": "(\\\\|/)app\\1assets\\1(?:javascripts|stylesheets)\\1(.+(\\.js|\\.css))(\\.[a-zA-Z]+)?$",
         "to": "/assets/$2?body=1"}

The toFile section specifies how it does saving from Chrome devtools. It iterates through the “from” regexes to match each resource url. If there is a match it converts it into a file using the “to” expression. It uses matching groups found with the “from” regex. The “to” path is relative to the base directory. In my example, RoR serves JavaScript resources from the relative directory /app/assets/javascripts and stylesheets from /app/assets/stylesheets. Both scripts and stylesheets are served using the relative url /assets/{filename}.

The fromFile section is for live reload. It’s relative to the base directory. It’s basically the toFile section in reverse. It’s optional because tincr will infer the file-to-url relationships from the toFile section. In some cases, the inference isn’t good enough. For example, with RoR, it’s common to use SASS and coffeescript. Because they are converted to css and javascript, you can’t do auto-save but you can do live reload. In my example above, the fromFile section is necessary because of this.