User defined folder paths in Grunt - node.js

am new to Grunt. Until this time i made a few tasks, compiler for less and sass, some watches.
I would like to have grunt in static folder, but when i start watch sequence i usually need to start it in folder where is my project placed = tons of separate grunts files and node-modules folders.
What i need: static folder for grunt and when i start it i will tell him as a user through console where i need him to watch files (which project). I need to set by user destinations and original folders.
Is it possible in grunt?
Thanks for help

I'm not really sure what you are asking, but a common node pardadigm is to allow users to configure dynamic options through env vars.
To do this grunt could optionally accept and env var
process.env.PATH_TO_WATCH || defaultPathToWatch
If provided it will allow the starter of the grunt processes to specify a dynamic PATH_TO_WATCH.
PATH_TO_WATCH=/some/path node start_grunt.js

Related

How can I change the path/file name of index.html in React?

When building a React (with usual react-scripts/create-creact-app etc.) app via npm build, I always get the entry file in build/index.html.
I've tried moving the src into a subfolder, but the index.js is required to be there in src/index.js.
So how can I change the output path of the index.html?
I.e. e.g. I want to rename it to index.htm, because I am have a pedantic quirk, or I want to change the output path to build/srv/www/index.html?
(These are just examples.)
To change the output path you need to change the webpack config, and in create-react-path is not possible unless you run the eject script.
This way:
npm run eject
After running it, you will be able to access to any project configuration (webpack config in your case), but you must know, once the project is ejected, you can't go back.
More information here:
create-react-app

Using Grunt on Heroku without defiling devDependencies

I understand, in general, the most frequent way Grunt is used on Heroku -- load the buildpack, specify your grunt heroku task(s), and include any Grunt plugins you want to use on the Heroku dyno in your package.json:dependencies.
However, I find this to be a rather poor solution, because it miscommunicates about my app. My Grunt plugins are all more like devDependencies, as I will only run anything with Grunt one time (per deploy). My app doesn't directly depend on them to run, as it's mostly minification and template compilation.
I'm also trying to keep compiled files (e.g. .css and .html files when I'm writing in Sass and Handlebars) out of source control, so pushing them over from Github is possible but definitely not what I want.
Is there a way to do all of the following?
exclude .css and .html files from Git
write stylesheets and markup using Sass and Handlebars
push a basic Express app containing these files to Heroku
have Heroku run a server-relative version of my grunt build task (naming it whatever is necessary is fine) to compile and prepare all of the views and assets before launching the web: process
have Heroku's Grunt task intelligently understand that I just want some pre-launch compilation so it will look at devDependencies and install the relevant ones in a perhaps-temporary kind of way
launch the Express server via the web: process
I'm fine with having to write my own buildpack, or whatever needs to be done to do this (what I perceive to be) the right way.
I created the buildpack heroku-buildpack-webapp-client that supports grunt, compass/sass and installs your devDependencies. Maybe you can use this one or have a look at the bin/compile script to see how it works.

sails.js v0.10 create new project --linker not working Gruntfile.js not used

With the default version of sails on npm (v.9?) --linker works ok i.e. creates /linker folder. I can copy js, css files to assets/linker/ and they appear in layout.ejs automatically.
I now have sails v0.10 installed both locally and globally. Using Node V0.10.25.
I created a new sails project using:
sails new project_name --linker
but no /linker folder is created.
I had to create /.tmp as it did not exist
I had to create /.tmp/public/linker/ to put /js & /styles
and add them manually into layout.ejs
I renamed Gruntfile.js and my program still works thus Gruntfile does nothing in the program.
Sails v0.10 no longer uses the linker folder--it was just causing confusion. If you have the linker option enabled, then any assets under your assets folder will be copied over to your .tmp/public folder by Grunt when Sails is lifted. The public folder will be created by Grunt as necessary. The grunt-sync task will then keep the folders synced as long as the program is running.
Sails projects are not dependent on Grunt, so renaming the Gruntfile (or removing it completely) won't stop the program from working, but that doesn't mean it's not doing anything when it's there! To see what Grunt is up to, you can lift Sails with sails lift --verbose.
As an add-on to sgress454's answer, the reason a .tmp folder is created is so that files like the ejs and less files can be compiled into formats that your browser will understand. It's similar to the way that when you compile Java, it converts to Java bytecode (just an analogy, definitely not the same process).There doesn't necessarily have to be any .tmp folder when you're not running the server though; this is something Grunt creates and is what the browser reads from. Hope this clarifies things a bit more.

Node or Grunt plugin to watch files access

We have lot of node modules and grunt plugins to watch the files that change, add or delete but is there any way we get the list of files being accessed?
I need to create a script in node or grunt.js to list down all the files being accessed in the web folder to remove the unused files. Any other suggestions are highly appreciated.
Thanks

Can I put the npm node_modules directory outside of my 'webroot'

I'm new to Node but am enjoying myself so far. I was trying to move my node_modules (libraries) directory outside of the public 'webroot' and need advice and guidance.
I've setup my simple expressJS based Node project as follows:
/my_project
/config
/public
/node_modules
server.js
I was wondering if there was any way I could have the /node_modules dir outside of my webroot and not break my application. I'm just so used to keeping the bare minimum in my publicly exposed webroot and don't feel right with the libs being in there. Call me old fashioned but that's how I'm used to doing stuff in the PHP and C# world.
If I setup the project as follows:
/my_project
/config
/node_modules
/public
server.js
then it all goes wobbly and Node's require() magic breaks.
I've tried the following:
var express=require('../express'); which doesn't work either giving me the 'Cannot Find module' type error.
Is what I'm asking even possible, if so then how?
Are there any major risks with me having my libs in a webroot or have I missed something fundamental here with the way Node works.
What do you guys do, what is best practice for production apps? May I have some examples of your production practices and why.
1. Is it possible to have modules in a folder outside of the project
Yes.
2. Are there any major risks with having modules in a webroot?
Assuming that you by "webroot" mean in the root of the server or any folder outside of your project: yes. It is possible to install modules globally with npm using the g-flag: npm install -g express. This generally considered bad practice as different projects may depend on different versions of the same module. Installing locally allows different projects to have different versions.
If you're using version control and don't want to check in the external modules, a common (and standard in npm) pattern is to ignore ./node_modules and specify dependencies in a package.json file.
3. "What is best practice for production apps?"
Not a good fit for SO, but since I'm at it I'll give it a shot anyway. If you use grunt (a very popular task automation tool) you'll usually end up with a structure like this:
/my_project
/node_modules
/lib
# actual project files
/public
# files that are meant to be sent to clients
/test
package.json # specifies dependencies, main script, version etc
README.md # optional
This structure has the advantages of clearly separating core files, dependencies and any tests while keeping it all in the same folder.

Resources