I understand when I run sails lift that the grunt tasks will run and put my assets in .tmp/. However, if I'm doing local development and want to make changes to some files in assets/js and refresh the page in the browser and see the updated code it seems I have to stop the server and re-lift the app.
I know there's a grunt watch task configured, and it seems like that is intended to handle this kind of thing. My questions are:
is the watch supposed to handle (for example) .js file changes and deliver the re-compilied/minified/concatenated/whatever'd scripts to .tmp/ without restarting the app?
if it is supposed to work like that, what common things should I check to troubleshoot why it's not?
As a side note, I'm running it with forever and simply ended up omitting **/assets/** from my .foreverignore file from what was listed in this answer. However, that still has the issue that the whole app is restarting when really I just need the asset pipeline run on change.
I disable Grunt during development and works fine for me.
This is how my .sailsrc looks:
"hooks":{
"grunt":false
},
"paths":{
"public":"assets"
}
Documentation:
http://sailsjs.org/documentation/concepts/assets/disabling-grunt
Related
Some things to know:
I understand how to make a HTML / CSS / JS website.
I understand how to make a Node JS app and host it on Heroku
I encountered a problem that was very confusing and I still working it out. I am making a firebase project using their latest tree-shaking V9 SDK
import { initializeApp } from 'firebase/app';
I understand Node JS is meant for backend (it can't be run in a browser) so how am I supposed to "build" this into something that I can reference in a script tag? I've heard of webpack but that requires you to run npm run build so how is that practical in any way? That would mean every change I make I would have to build it?
Developer Testing:
How would one live preview this Node JS app on a localhost if Node JS can't be run in a browser? I would live to be able to preview this Node JS app and quickly make changes if that's possible.
I've heard of webpack but that requires you to run npm run build so how is that practical in any way? That would mean every change I make I would have to build it?
Yes, that's the general idea. You make changes to script files on your local machine (or network), and then in order to see the changes take effect, you rebuild the app so that a new bundle is generated. This bundle can then be hosted on your web server or development server, and once it's there, you can refresh the page to see the differences.
But almost all of this can be automated, resulting in it not really being much of a chore at all.
Nodemon is a popular tool that watches a directory for changes and can run Node scripts when a change is detected. With it, you could, for example, make a change to a file, and then it'll automatically rebuild your app.
For Webpack in particular, there's webpack-dev-server, which can automatically refresh a page when the app gets rebuilt.
So, during development, the workflow can be as simple as - make a change, then alt-tab to your browser (hosting the app on localhost) to look at the changes.
Bundles built for the purpose of eventually hosting them on the front-end can easily incorporate Node modules - the build process can take the code from the module, and the bundle produced can include that code. This sort of thing is extraordinarily common.
I have this program where a server is made. Before the server can start though I need to register it. This is a one time thing as re-registering it will change all the dcom data and settings to factory settings. Which I don't want. So What I have set up is a JS file that runs my program and gives it a parameter argument "register" which is handled in my program to register the server. Similarly before uninstalling I want to run a similar JS file that passes an unregister argument so the server is no longer listed on client views after it's been removed. To be clear I have both of these JS files working fine and they successfully register/unregister my server as needed.
My issue is that I've added these files in the application directory and in my Visual studio installer: Setup Project, I have gone to right click installer project > view > custom actions. Then I right clicked the install folder and added my regserver.JS file and similarly for uninstall I've added my unregserver.JS file. The problem lays in the order that these get run. When the intaller runs it first run my regserver.JS. This is bad because there is no .exe of my program existing yet so an error is thrown... Is there a way to specify in my project that this JS is only to be executed AFTER the installation finishes?
Or is there a clever wrap around to this? Maybe I'm doing it all wrong!
EDIT: ..just an idea... what if I make ANOTHER two JS files that delay for like 30 seconds while the installer runs and then they execute my regserver/unregserver files... Really sloppy but I mean it might work...
I am using Grunt to compile our Javascript into a single file, app.js. I am using Grunt inside of intelliJ via the grunt window to fire off a watch that will compile on change.
When a change is made, the grunt task runs and the files are compiled. Next I blur intelliJ, to update the resources on the tomcat server and refresh the browser.
The change never makes it to the tomcat server because intellij doesn't catch that the files have been updated via grunt.
For example: I can make a change and then open the newly compiled app.js file and see the change has not been applied. If I update resources in the project explorer I see the change, and can update it on the tomcat server via frame deactivation.
Is there a way to keep intelliJ synchronized after a grunt build/task fired from a watch?
Turns out IntelliJ 14 has a bug with registered watch tasks in grunt.
When you run watch via a registered task IntelliJ won't synchronize the files after each run.
If you run watch directly everything should work as expected.
This functionality is fixed in the next version of IntelliJ.
You can follow my conversation on you track here
https://youtrack.jetbrains.com/issue/WEB-14876
I have grunt watch setup so when i`m developing my files are automatically compiled, but after I pull i need to "touch" the files in order to trigger recompile the new files in case watch was not running while I pulled, is there a generic way to make grunt track last edit for files without having to "touch" the new files or should i just have grunt watch running before I pull (which while writing this seems like an adequate solution)?
Just have the watch run while you make the pull, or just run the tasks manually--the kind of detailed tracking you're suggesting just seems like overkill to me. Keep it simple!
I am in the process of converting an existing Rails 3.1 app I made for a client into a Backbone.js app with the Rails app only as a backend server extension. This is only a personal project of mine, to learn more about Backbone.js.
While setting up Backbone.js (using Backbone-on-Rails), I noticed I have some dependencies (like backbone-forms) that come from external sources and are frequently updated.
I've grown accustomed to using Bundler to manage my Ruby gems, but I haven't found anything similar for JavaScript files. I'm wondering if there is any way to do the same for Javascript (and possibly css) files.
Basically I can see three possibilities to solve this issue:
Simply write down all the sources for each JS file and check these sources from time to time to see what has changed.
Use some kind of existing "Bundler for Javascript" type of tool, I've been looking for something like this but have yet to find anything (good).
Since most of these JS files will be coming from Git anyway, use Git to get the files directly and use checkout to get the latest version from time to time.
I prefer the last option, but was hoping on some more input from other people who have gone this route or preferred some other way to tackle this issue (or is this even an issue?).
I figure the Git way seems easy, but I am not quite sure yet how I could make this work nicely with Rails 3.1 and Sprockets. I guess I'd try to checkout a single file using Git and have it be cloned in a directory that is accessible to Sprockets, but I haven't tried this yet.
Any thoughts?
You don't mention it in your alternatives, but ideally you should use something like Maven to manage your dependencies. Unfortunately, there are no public repositories for javascript files. This discussion lists some other options which might be of help to you: JQuery Availability on Maven Repositories
For now I've settled on using the Git solution combined with some guard-shell magic.
The steps I follow:
Create a dependencies directory somewhere on your local drive
Clone the repositories with javascript (or css) files you want to use in the app
Set up a custom guard-shell command to do the following:
group 'dependencies' do
guard 'shell' do
dependencies = '~/path/to/dependencies/'
watch(%r{backbone-forms/src/(backbone\-forms\.js)}) {|m| `cp #{dependencies + m[0]} vendor/assets/javascripts/#{m[1]}` }
end
end
Place the Guardfile at the root of the app directory
It takes some time to set things up, but after that, when you have the Guard running, and you pull changes into your dependencies, the required files are automatically copied to your application directory, which are then part of your repository.
It seems to work great, you need to do some work for each new file you want to include in the asset pipeline, but all that is required is cloning the repository in your dependencies directory and adding a single line to your Guardfile, for example for the backbone-form css:
watch(%r{backbone-forms/src/(backbone\-forms\.css)}) {|m| `cp #{dependencies + m[0]} vendor/assets/stylesheets/#{m[1]}` }
Also, the reason I added this Guard to a group is because I keep my dependencies outside the main application directory, which means guard normally doesn't check my dependencies directory. To make this work, I start up my main Guard processes using bundle exec guard -g main and use bundle exec guard -w ~/path/to/dependencies -g dependencies in a new terminal window/tab to specify the -w(atchdir).