Received: by 10.68.223.73 with SMTP id qs9mr2840338pbc.7.1343077391276; Mon, 23 Jul 2012 14:03:11 -0700 (PDT) X-BeenThere: google-chrome-developer-tools@googlegroups.com Received: by 10.68.240.172 with SMTP id wb12ls20706146pbc.3.gmail; Mon, 23 Jul 2012 14:03:09 -0700 (PDT) Received: by 10.68.216.163 with SMTP id or3mr2204096pbc.1.1343077389601; Mon, 23 Jul 2012 14:03:09 -0700 (PDT) Date: Mon, 23 Jul 2012 14:03:07 -0700 (PDT) From: ryanack...@gmail.com To: google-chrome-developer-tools@googlegroups.com Cc: ryanack...@gmail.com Message-Id: In-Reply-To: References:

Subject: Re: [Chrome DevTools] [ANN] New Chrome devtools extension for doing auto-save and live reload MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_442_4193742.1343077387716" ------=_Part_442_4193742.1343077387716 Content-Type: multipart/alternative; boundary="----=_Part_443_19926706.1343077387716" ------=_Part_443_19926706.1343077387716 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks for taking an interest Nikita. I forgot to add the docs for this. I will add it ASAP. In the meantime, This is the one I used for testing. It's for RoR. { "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. 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. ------=_Part_443_19926706.1343077387716 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks for taking an interest Nikita. I forgot to add the docs for thi= s. I will add it ASAP. In the meantime,

This= is the one I used for testing. It's for RoR.

{

=09"toFile" : [

=09=09{"from": "/assets/(.+\\.js)",

=09=09<= /span> "to": "/app/assets/javascripts/$1"},

=09=09{"from": "/assets/(.+\\.css)",

=09=09 "to": "/app/assets/stylesheets/$1"}

<= div>=09],

= =09"fromFile" : [

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

=09=09= "to": "/assets/$2?body=3D1"}

=09]

}

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.

The fromFile section is for live reload. It's relative to the base dir= ectory. 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 c= ommon to use SASS and coffeescript. Because they are converted to css and j= avascript, you can't do auto-save but you can do live reload. In my example= above, the fromFile section is necessary because of this.

------=_Part_443_19926706.1343077387716-- ------=_Part_442_4193742.1343077387716--