Firstly, if you don’t know the answer but can think of a better place I could ask this question outside of FCC please let me know; I am struggling to find the right “forum” to ask these types questions, for example if I were to ask this on StackOverflow I’d get slaughtered as it’s not a coding question.
Since then I have become a novice web developer and can figure out most of it however I still have some questions:
The Grunt “build” command builds the site from the assets folder, runs uglify and other bits to get the site ready for prod. It gets most of the files from the “assets” folder. I’m guessing some of the JS files in there are the author’s own scripts and not just vendor libraries. When he would have been building the dev version of the site would he have referenced these scripts/libraries from these folders? IE some libraries are in node_modules so would he have had his tags linking the scripts to this location?
Then when the build task runs to make it the prod version does it somehow update the tags to the new scripts location?
I can’t see how the site would run without first running the Grunt build task so how would the original author make changes to the site and test it? Would he have to edit the CSS/JS files in assets then run Grunt build each time? Because he cannot edit prod version of the files as they have been uglified right?
Grunt is a task runner: it lets you use a simple language to define a set of tasks that otherwise you would need do manually. Then you run Grunt. Grunt then runs the tasks in the order you’ve defined them.
They’ve installed the build tools (Grunt plus plugins) using NPM; when that’s done, they are saved into the node_modules folder. They’ve also installed three libraries that they’re using in the code.
All the JavaScript files used are joined together into a few files using uglify, and those output files are referenced in HTML script tags.
I would first of all try to understand how NPM works, going though a beginners guide (I’ll try to put together a more thorough description, it is complicated when you’re just starting)
Grunt and Gulp are two entirely different build tools. In Grunt you define your tasks declaratively through a config file, and the grunt runtime figures out how to run them. In Gulp, you define a task flow explicitly, but you have more control over each part. Gulp came after Grunt, and was designed to address a lot of of Grunt’s shortcomings. Its pipeline model makes it a hell of a lot faster than Grunt.
Both Grunt and Gulp have largely given way though to Webpack and similar such as Rollup and Parcel, which go back to a declarative config like Grunt but offer much more power with it.
Ah feck, edited. Halfway through I forgot it was Grunt. Webpack is possibly a bit overkill here, not sure I’d want to advise that here at first, just using NPM scripts is possibly easiest to explain (?)
Edit: the way the Grunt config is defined for the tasks and plugins is super clear. It’s been years since I used it, I remember it being incredibly transparent w/r/t how it worked – because it actually writes all the temporary files, can literally watch it working through the stages. Also remember it being quite slow because of that, but it’s a v nice API
Yeah, true. I guess I’m biased against it due to how much of a massive pain in the ass it used to be, I still hate having to configure it (I find it highly unintuitive even on newest version). It used to be something you’d call from Gulp, and now everything seems to have been shoehorned into it to make it into a task runner rather than a module bundler
Yeah, most webpack configs are something I have to cargo-cult from a google search first, then figure out what it’s doing. I hate configuring webpack, but I’m glad I have it when I’m done fighting it.
If memory serves, grunt was no picnic to configure either.
Thanks for you answers guys. I understand now Grunt and NPM works, my questions were around the authors reasons for following that approach. The missing link for me was where he kept his original dev website. It looks like it’s not there. Would there be one usually and he just didn’t include it in the repository? Easier if I explain what i think he does.
He works on the dev version web pages(not in the repo so I may be wrong but I’m guessing he just didn’t upload it). This dev version has all the original JS and CSS in their original forms and possibly references the assets folder (where the original files are). When he is ready to productionise it, he run the build script does all the above.
If the above is incorrect then why even both with the grunt task? Why doesn’t he just upload the the prod version after he ran the build tools? What I’m saying is that the only reason I can see that he would upload the repo in an unbuilt state is if there was a dev version originally which he used to work on then run build at the end.
If I am complete wrong lol then I was wondering if there are tools that do this? Like say I a have version of my site which will ref files from different paths; when you a build task like above can it re-write bits of your HTML code to point to the new paths?
He doesn’t need to keep the built website anywhere in that repo: all he does is run the build script locally. That gives him a folder which contains everything necessary for the prod version. Then he just plops the contents of that folder on a server somewhere – so, for example, he could just drag and drop the folder into some hosting GUI. Or copy the contents across using some command-line program. Or the repo could be hooked into a CI service, and when a push happens on the repo, run the build script then deploy using command-line tools on the CI server.
There are lots of automated tools that will do this – for example there will be Grunt plugins that deploy to hosting as a final step (you’ll provide some security/url/etc details in the config, then normally as the final step in the build it would copy the files to the hosting). He doesn’t seem to have done this afaics, so it’ll be some manual step
Sorry, I don’t think I’m explaining myself clearly. I know about the prod bits. What I am trying to figure out is how he would do DEV work. Look at it this way, let’s say I DL the repo and want to work on it myself. Here is what I’d have to do if I were to change some JS code:
Firstly run the build script, then run the server. Maybe run a debugger to find the JS code I want edit or add new feature. Now at this point I am viewing the uglified version which isn’t much help as it’s very hard to read. So I’d have to get the original JS files (from assets folder) and drop them into the prod location (dst folder i think) and change the header in the webpage to reference these un-unglified files and run the debugging again. When I eventually find the code I want to edit, I’ll amend it and test again. let’s say it now works. I’d then have to copy that JS file back to the assets folder and re-run the Grunt task to rebuild the uglifed version. It’s bit long winded don’t you think? An easier and better way would be to have a dev version of the site (which I can’t see in the repo so I’ve made an assumption he just didn’t upload it) and this version is the un-uglified version. He does all the debugging, testing and adding new features here and only needs to run the build task once at the end when he is happy with all his changes.
This is my assumption because using this assumed approach is far more efficient than the first approach he’d have to take without a DEV version of the site anywhere. What I am asking is whether my assumption is correct? If no, then the first approach seems inefficient and long winded, so how would he make changes to his code and test it effectively without using the long winded approach and no DEV site? If all this sounds silly then there is probably a better to do this but I don’t know what is; so please tell me how you would approach this task of adding new JS code without a DEV site to work with. Does that make sense?
There are grunt tasks that will start a local dev server on your machine serving your code, automatically connect a browser to it, and reload it every time your code changes. And you won’t get the uglified JS either, because it will disable uglify (that or it’s a quick task for you to disable it in dev). It ought to be one of the dev dependencies in your project, and if it’s not, it should be.
Have you considered asking your colleague what his workflow looks like?
"--------",
"Setup Instructions:",
"--------",
"1. npm install",
"2. grunt build",
"",
"--------",
"Development Instructions (no webserver needed!):",
"--------",
"3. grunt server",
"",
"Open your web browser of choice and visit http://localhost.",
"#1 installs npm dependencies for this project.",
"#2 builds the project to the dist/ folder.",
"#3 runs a web server using node/express in background. Watches for changes to any files in the assets folder and if a change is detected, ",
"the build task is executed immediately so the results are visible your browser."
he’s not my colleague, don’t know where you got that from. I just got access to the repo cause it is public. I tried to contact him through Github but he never replied. I think his account is dormant.
@DanCouper Ahh!! And there is the missing bit of info I was on about! I see now. I did read that package.json file but I read it a while back when my knowledge was even less than it is now! I didn’t understand it at the time and haven’t gone back since to read it again. I see now that you edit it in assets and it auto compiles it. Thanks for pointing that out.