Develop Reference

Config files editable after `npm run build`

I'm deploying a web app using react-redux soon and I was wondering if it was possible to let the user using the production version to modify a config file so that he can set his own initial settings.
Is it possible, after I run npm run build, to have a config.js file in the build folder that the user can go and directly modify?
If not, is there any better way to accomplish that using another strategy?
Thank you

If I understand correct you want to expose a API to change some of settings in config for end user and then somehow restart your API servers to apply those changes.
Always a dangerous way of doing things. You can expose functionality to change few of fields of config for end user and when applied restart the node process. There are few ways to restart node process from code itself or writing a hot script which monitors changes in source directory.
But beware its risky thing to do. Hope this helps.

Sails.js run asset pipeline on js file change

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

IntelliJ, synchronize files after grunt build

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

Developing js while using elixir

I am developing the js of a laravel-5, AngularJS app right now. I am using elixir to version the css and js files. However while I am developing I don't want to have to have to version my files everytime I want to test something.
What is the best way to use elixir while you are still in active development?
I know you can use gulp watch but won't that create a new compiled version of the code everytime I save? Those files could add up fast.
Related Question: Should I commit the built files to version control?

After having developed with gulp for a few weeks now, gulp watch is really good at quickly recognizing the change and firing a rebuild on the file. Plus, it does delete the previous file.
So, Elixir keeps only 1 compiled version of each file. And it builds them quickly so gulp watch is a good solution.
Personally I think it is a very bad idea to version these files. For one they are always being deleted and recompiled. Lastly it is generated code that can (and should) be generated in production.

Bundler for javascript, or how to source control external javascript files

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).