The discussion revolves around finding a faster way to develop plugin theme CSS and JS in Discourse, with a focus on livereload/auto-injected CSS functionality.
kara-todd initially asks for help, mentioning that they’re developing a custom plugin with SCSS files and would like to get live reloading working. sam responds, suggesting that auto-injected CSS already works, but kara-todd clarifies that they’re not developing a theme in the admin panel.
sam points out that the live reloader should work as long as Puma is launched, and kara-todd attempts to use it but encounters issues. The problem is eventually identified as being caused by Vagrant, which breaks file watching (sam).
kara-todd resolves the issue by setting up a local Discourse install, and live reloading starts working as expected.
The conversation is later extended to JavaScript files, with eatcodetravel asking if live reloading should work for them too. sam seeks input from eviltrout, who responds that JavaScript editing is generally smooth, with cache issues only arising when adding or removing plugins.
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.
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?
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.
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.
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…
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
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,
I checked out your plugin
Ran bin/puma
Edited header.scss and added `body { background-color: red !important; }
The background turned red, no need to reload the page or anything.
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?
