Is there a faster way to develop plugin theme CSS / JS (e.g. livereload)?


(voxelfox) #1

Hey there,

I’m trying develop a custom theme/plugin which will add a few additional templates and some general styling to discourse.

In pursuit of this, it would be great to get some kind of livereload/auto-injected CSS action going on, as reloading the page and wating 2s to notice I have made a typo is slowly adding up to quite a significant chunk of time. :slight_smile:

It seems like the recommendation is to use autopec, but I’m a little confused as to how this is supposed to work.

I have discourse setup and running locally using vagrant. I’ve ssh’d into the box and can run the server, see the admin page etc.

Should I run autospec and then start the server? or vice-versa? Will this effectively work to live reload the CSS so that I don’t have to refresh the app? Or am I just completely off-base here?

Any suggestions would be appreciated. :slight_smile:


(Sam Saffron) #2

This already works, just click preview on the theme and it will update as you go.


(voxelfox) #3

Thanks @sam I think I wasn’t clear in this case.

I’m not developing a theme in the CSS section of the admin panel.

Rather, I’m creating a plugin which contains raw scss files which “themes” the discourse instance and also some of the custom elements that I will be injecting into outlets.

So I have a css files being loaded by my plugin:

plugin.rb
register_asset "stylesheets/base-theme.scss"

I’d really like to get these live reloading (similar to guard-livereload,)

Developing in the admin isn’t really sustainable from my viewpoint as there are going to be several developers working on files and having version control / git commit flow process is a pretty high priority.


(Sam Saffron) #4

I think the live reloader should work as long as you launch puma


(voxelfox) #5

Ok. I think this my confusion.

So for example,

I start my server with bundle exec rails s -b 0.0.0.0 and then visit my local environment at http://127.0.0.1:4000/ (bound port through vagrant.)

If I then make any changes to the scss I don’t see any changes until I manually refresh the page (which takes a few seconds.)

If I understand correctly, puma should be running when I bundle exec rails and changes are being picked up but I just have to hit reload on the page… the styles are not injected into the app live…

Am I missing a step?


(voxelfox) #6

I have been previously been developing a standalone ember app so I have been hopelessly spoiled by ember server :wink:


(Sam Saffron) #7

Try bundle exec puma, does it work?

I will test out plugin live reload on Monday I may have missed something

Certainly works for themes and discourse assets


(Sam Saffron) #8

Link me to the plugin repo you have, either here or via a pm so I have something to test :blush:


(voxelfox) #9

As an update to this @sam here’s what I’m seeing when I boot my server. I PM’d you details for the codebase I’m using.

vagrant@discourse:/vagrant$ bundle exec rails s -b 0.0.0.0
=> Booting Puma
=> Rails 4.2.8 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Staring CSS change watcher
Puma starting in single mode...
* Version 3.6.0 (ruby 2.3.1-p112), codename: Sleepy Sunday Serenity
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:3000D

(Sam Saffron) #10

I just confirmed that live-reload works fine with the plugin you linked me.

The issue is vagrant. Vagrant mounts stuff in a terrible way and breaks inotify/kqueue file change notification. This leaves you stuck with all file watching broken from what I can see.

I recommend you avoid vagrant and just do a local Discourse install.

For my test,

  1. I checked out your plugin
  2. Ran bin/puma
  3. Edited header.scss and added `body { background-color: red !important; }
  4. The background turned red, no need to reload the page or anything.

(voxelfox) #11

Thanks Sam!

I followed the instructions for setting up discourse locally and now it’s working for me as well. :smiley:

This will make my life much easier so thank you very much for your time on this.


(Orlando Del Aguila) #12

Hey @sam,

Should this work for JavaScript files too?, I’m trying it but I have to remove the cache every time I add/edit a file.

I added this line to see if sprockets pick up new changes and it works without removing the cache.

# config/environments/development.rb
config.assets.paths += %W(#{config.root}/plugins/<plugin-name>/assets/javascripts/**/*)

Should we add this by default in development? (for all plugins instead of a specific one), or there’s a better way?


(Sam Saffron) #13

I am cleaning up my bookmarks, @eviltrout you do a lot of JS are you noticing any cache issues amending JS in plugins? Do we need to add an assets.path?


(Robin Ward) #14

No, Javascript is more or less perfect for editing, plugins and all. The only time you have to clear tmp is when you add or remove one.

The reloading issues I have are always on the server side.