[ANN] New Chrome devtools extension for doing auto-save and live reload

[ryana...@gmail.com]

Hi all,

I've just released the first version of my devtools extension called Tincr (pronounced link "Tinker") :

http://tin.cr

Tincr is a tool that arose from my own frustration with switching back and forth between Chrome Developer Tools to do debugging and my text editor to do coding. The idea behind Tincr is that you can save changes to your original source file from within Chrome Developer Tools. In addition, Tincr does auto-reloading of JavaScript and CSS changes made in other editors.

It was partly inspired by two projects 

• Nikita Vasilyev's auto-save extension
  
• http://livereload.com/

I've used NPAPI to make the functionality self-contained in the extension. It doesn't require a proxy server or a separate application to interact with the file system. Even though it uses native code, it should work on OS X, Windows, and Linux. 

I'm also trying to make it dead simple to configure for common web development platforms. 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 without refreshing the whole page   

It should "just work" for local files accessed at "file://" urls. It currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS, etc. but I'm working on that right now. 

I'm trying to get it released on the Chrome Web Store but since it contains an NPAPI plugin it's taking a while (it has been Pending Review for 11 days now). 

It's open source and it's hosted on bitbucket.

[Andrey Kosyakov]

FWIW, there's also devtools-save that also uses a NPAPI plugin to save locally:

http://code.google.com/p/devtools-save/downloads/list

[Nikita Vasilyev]

How does a configuration file (tincr.json) may look like? I haven’t found any documentation and I don’t feel like reading the source code.

[ryana...@gmail.com]

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.

[Nikita Vasilyev]

Thanks for the response, Ryan!

On Jul 20, 2012, at 8:04 PM, ryanackley wrote:
> It currently doesn't do pre-processing of things like CoffeeScript, SASS, LESS, etc. but I'm working on that right now.

How exactly are you going to fix it?

[ryana...@gmail.com]

For something like Rails, it's not necessary since the Rails engine handles the conversion. It only applies to file:// urls.  

My first iteration will only handle stuff that can be converted with pure javascript (i.e. LESS, Coffeescript). For things like SASS, I will need to write native code to shell out a ruby process unless I can find a better way. 

[Nikita Vasilyev]

So, you’re not going to implement DevTools to filesystem direction, only the other way around. Is it correct?

I want to edit preprocessed code via DevTools. E.g.:
* Coffeescript
* SASS, Less, Stylus (including editing via Elements tab, Styles pane)

I think it’s utterly unfeasible.

[ryana...@gmail.com]

Yes, right now it's unfeasible but with sourcemaps it seems trivial for the devtools team to add an even to the extension api for when someone tries to edit and save a source mapped file. 

[Ryan Ackley]

Why wouldn't updating the live image be as simple as
"resource.setContent" with the new processed content and a sourcemap.
The problem with the scenario right now is that I believe
onResourceContentCommitted is called after resource.setUpdate. In the
case of files that needed to be re-generated, it would need to be
called before. So you need something like
onBeforeResourceContentCommitted.

> and probably not interesting anyway. More practical and interesting would be
> dedicated extension panels for editing artifacts that are meaningful to
> developers at the level of these languages.

Why not in the existing Scripts/Source panel? Devtools already has 2
panels that present an editor and file-like heirarchy in a side panel.

What about a plugin point for the editor in the Scripts panel? That
way someone could inject an ace/orion/codemirror editor and do other
cool stuff like auto-complete. I would write an extension for it if
there was a plugin point. I might even volunteer to write the plugin
point if you guys aren't already working on something like that.

[Ryan Ackley]

Yours didn't appear to reach it either. I just went to the google
group interface to reply to you and I didn't see it. See John's mail
below.

On Wed, Jul 25, 2012 at 1:22 PM, John J Barton wrote:

> Isn't that the event we already have, onResourceContentCommitted? I guess
> that editing the source files (eg in coffeescript, Less) should work just as
> well as js/css sources.
>
> Updating the live image is quite another matter, since devtools has no idea
> how the source and the live image are related. Mapping changes in the live
> image, eg editing via the Elements and Styles panel, would be very difficult

> and probably not interesting anyway. More practical and interesting would be
> dedicated extension panels for editing artifacts that are meaningful to
> developers at the level of these languages.
>

> jjb

On Wed, Jul 25, 2012 at 9:48 PM, Vsevolod Vlasov <vse...@google.com> wrote:
> Ryan, could you please share the message you were answering to here? It
> doesn't seem to have reached the mailing list.

> --
> Thank you,
> Vsevolod Vlasov (vse...@google.com)
>

[Ryan Ackley]

> Ultimately the user will be editing source, eg JS or CoffeeScript. When they
> save, listeners to onResourceContentCommitted get called. Those listeners
> can 1) save the source, eg to disk/cloud/etc and 2) process the source, eg
> live update JS or compile to JS then live update JS. So it seems like the
> event is already available right?

I think we're on the same page. To clarify, I think there is a subtle
but technically relevant difference in the way things are handled
right now. I could be wrong but I believe the current event gets
called after it's successfully updated in the Web Inspector backend.
This won't work for Coffeescript since we would need to capture the
event before it's sent to the backend so we could turn it into
JavaScript before it tries to update the backend. This is what I was
getting at with an 'onBeforeResourceContentCommitted' event.

On Thu, Jul 26, 2012 at 3:54 AM, johnjbarton <johnjba...@gmail.com> wrote:

>
>
> On Wednesday, July 25, 2012 3:26:30 AM UTC-7, Ryan Ackley wrote:
>>
>> Why wouldn't updating the live image be as simple as
>> "resource.setContent" with the new processed content and a sourcemap.
>
>

> Because the resource is source, eg a Less file.

>
>>
>> The problem with the scenario right now is that I believe
>> onResourceContentCommitted is called after resource.setUpdate. In the
>> case of files that needed to be re-generated, it would need to be
>> called before. So you need something like
>> onBeforeResourceContentCommitted.
>
>

> Well right now I think only JS can be edited anyway, but the entire
> Resoure/UISourceCode system is in flux.
>
> Ultimately the user will be editing source, eg JS or CoffeeScript. When they
> save, listeners to onResourceContentCommitted get called. Those listeners
> can 1) save the source, eg to disk/cloud/etc and 2) process the source, eg
> live update JS or compile to JS then live update JS. So it seems like the
> event is already available right?

>
>>
>>
>>
>> > and probably not interesting anyway. More practical and interesting
>> > would be
>> > dedicated extension panels for editing artifacts that are meaningful to
>> > developers at the level of these languages.
>>
>> Why not in the existing Scripts/Source panel? Devtools already has 2
>> panels that present an editor and file-like heirarchy in a side panel.
>
>

> Sorry I should have said "dedicated extensions for editing such artifacts".
> Extension authors may choice to use the Source panel or another panel.

>
>>
>>
>>
>> What about a plugin point for the editor in the Scripts panel? That
>> way someone could inject an ace/orion/codemirror editor and do other
>> cool stuff like auto-complete. I would write an extension for it if
>> there was a plugin point. I might even volunteer to write the plugin
>> point if you guys aren't already working on something like that.
>
>

> Jan Keromnes is working on this, but it's orthogonal to the issues above.
> ace/orion/codemirror don't compile CoffeeScript/Less/SASS either.
>
> jjb

[Nikita Vasilyev]

I often just have 'public' folder that mapped to a website, e.g. "mysite.dev/style.css" is "public/style.css" on a file system. I don’t really want to create configs. I just want to choose a base directory that matches mysite.dev.

It’s basically the same routes written twice. Wouldn’t it be better to just use boolean flags:

[

{"from": "/assets/(.+\\.js)",
"to": "/app/assets/javascripts/$1",

"saveToFS": false,
"updateBrowser": true}
]

(I’m not sure about the names thought)

Anyway, I see config files as a step backward. The latest Autosave uses GUI for that. I’ve found it much more user friendly.

[Nikita Vasilyev]

I just noticed "Auto-Refresh" and "Auto-Save" checkboxes, so I don’t really see any reason to have neither the fromFile section nor the boolean options.

[Ryan Ackley]

Hi Nikita thanks for digging into it and giving me more feedback. Let
me clarify a few things. One of the core concepts behind tincr is that
I wanted there to be almost no configuration for the end user. You
choose the application type and then point it at your project's base
directory.

I only did a handful of project types for the initial release based on
the types of projects I work on and the way I work. When I do
development on static files, I use file:// urls so I didn't think of
it. File:// urls should just work with no configuration. Mapping a web
server url to a local directory seems like a common use case so I will
add that.

The tincr.json config is used as a fallback/catch-all project type.
The idea was that you could use this if you didn't feel like writing
the code for a new custom project type.

[John J Barton]

On Tue, Jul 24, 2012 at 5:55 PM, <ryana...@gmail.com> wrote:

Yes, right now it's unfeasible but with sourcemaps it seems trivial for the devtools team to add an even to the extension api for when someone tries to edit and save a source mapped file. 

Isn't that the event we already have, onResourceContentCommitted? I guess that editing the source files (eg in coffeescript, Less) should work just as well as js/css sources. 

Updating the live image is quite another matter, since devtools has no idea how the source and the live image are related.  Mapping changes in the live image, eg editing via the Elements and Styles panel, would be very difficult and probably not interesting anyway. More practical and interesting would be dedicated extension panels for editing artifacts that are meaningful to developers at the level of these languages.  

jjb

[Vsevolod Vlasov]

Ryan, could you please share the message you were answering to here? It doesn't seem to have reached the mailing list.

On Wed, Jul 25, 2012 at 2:26 PM, Ryan Ackley <ryana...@gmail.com> wrote:

[dennis...@gmail.com]

Hi!

This is exactly what I've been looking for - nice work!  

Is there anyway to debug it?  I'm using the 'Http Web Server' configuration, have my root directory set and tincr indicates the project was loaded successfully, however, when I save .js change they aren't reflected in the source file.  Not seeing any log entries in my console window.

Thanks!

[Ryan Ackley]

Hi Dennis, try re-selecting the root folder with the log checkbox
ticked. You should see some message from Tincr on the console stating
if it was able to match up the files running in the debugger with the
files on the filesystem. If there are no messages then the paths
aren't matching up. The root of your localhost path should correspond
to the root of the directory you select.

-Ryan

[dbext...@gmail.com]

Quick update: configured my Java app to execute from the root, and tincr is now working fine.  Nice work Ryan - this tool is great!

[dbext...@gmail.com]

Still no love.  I'm going to go out on a limb and guess it has something to do with my setup: 
 - I'm using Tomcat as my server 
 - My server side application is Java based 
 - The application context root is myapp 
 - so the URL: is localhost:8080/myapp/index.html 
 - the directory I map to is: /...bunch of dirs../myapp/src/main/webapp 
 - index.html resides under the webapp directory 
 - I'm guessing Tincr is looking for myapp/index.html - what do you think? 
 - I'm going to try deploying my application to the root of Tomcat server, that way the URL will just be /index.html which would map to under the webapp directory. 

Thanks! 
- Dennis 

[juri.stru...@gmail.com]

I'm using Tincr for a couple of days now and I love it so far.

Just some suggestions.

• Could you add a notification in case the saving fails? Devtools Autosave does something like this which is extremely useful. This because otherwise there is always this strange feeling whether the changes have really been saved correctly (you know, readonly files, wrong Http server root folder etc....) Otherwise one has continuously to go and look whether everything is fine

Another thing I notices is that the auto-refresh worked on my MacBook with OSX Mountain Lion but didn't on Win7 (same Chrome release channel). Any suggestions what could be the problem??

Thx a lot

[Ryan Ackley]

Hi Juri,

Thanks so much for the suggestions. You found a bug in the windows
version. I wasn't converting all "/" to "\" on Windows only the first
occurence. I'll be releasing a new version shortly to fix it.

I've created a separate google group for Tincr so my announcement
thread stops hijacking the devtools group :)

https://groups.google.com/forum/#!forum/tincr-for-chrome-devtools

Please post any future suggestions, problems, etc. there.

-Ryan

[scottsa...@gmail.com]

Could you post this little tidbit of info on the docs.html page? The way it is explained here was quite helpful and could have saved me about 35 minutes of troubleshooting. Love the extension! Thanks a lot!

- Scott

On Sunday, August 26, 2012 3:47:27 PM UTC-4, Ryan Ackley wrote:

[nastasea...@gmail.com]

Hello, I'm having a little problem with TINCR -> It's not modifying the file in the editor or reloading the page  ... I've installed it and trying to use it on a website that is online on which i'm doing changes to style.css locally and on save (in SUBLIMETEXT) it uploads it automatically. I've did the setup in the TINCR tab in devTools for that website, pointed tincr to the root directory on my computer and checked both save and live reload (i'm using windows8 but I had the same problem when I was using windows7) and still nothing ... I love the idea it's amazing but it's not working for me ... What am I doing wrong ?

[hamp...@gmail.com]

this seems too good to be true, I can't wait to try it out

full disclosure I am a non-programmer working in simple html / css

[hamp...@gmail.com]

changes made in the stylesheet autosave and register perfectly (as shown in the video on your site). changes made in the actual html file do not.

this is a good tool, but I will continue trying to find a way to edit the html file itself from chrome devtools.

[Vsevolod Vlasov]

Consider using workspaces: http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/#toc-workspaces

On Thu, Aug 8, 2013 at 1:07 AM, <chris.em...@gmail.com> wrote:

+1 for this! Would love a way for the html changes to get saved too!

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Hampton Myers]

Thank you.

You received this message because you are subscribed to a topic in the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-chrome-developer-tools/P7GvVl7qZfA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-chrome-develo...@googlegroups.com.

[luca...@gmail.com]

Workspace is still not addressing this issue. You will not be able to edit html directly in your "inspect element" tab.

Anybody knows how to achieve this task ?

Thanks

On Monday, 12 August 2013 12:20:14 UTC+1, Hampton Myers wrote:

Thank you.

On Aug 12, 2013 4:02 AM, "Vsevolod Vlasov" <vse...@chromium.org> wrote:

Consider using workspaces: http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/#toc-workspaces

On Thu, Aug 8, 2013 at 1:07 AM, <chris.em...@gmail.com> wrote:

+1 for this! Would love a way for the html changes to get saved too!

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-chrome-developer-tools/P7GvVl7qZfA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

[Pavel Feldman]

You can surely edit any files including html via workspaces.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/663f71c6-9cbe-48d2-bbfe-44e488ea42ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luca Aliberti]

Hi, thanks for the answer. Edit files from source tab does not give you real time live edit. You will have to save the page you are editig and reload it !