Uglyfing files, bundling js, separating dev and production environments, automting comments and more...
I sometimes struggle to organize my code in a way I know it won't hurt me in the future. This template is an attempt to make many of the "behind the scenes" tasks automated and have a solid starting point for all of my web projects moving forward. Tasks like minifying and combining js files, compiling SCSS into CSS, uglifying and bundling them again should be set up once and used throughout all my projects.
All modules are included through npm. Npm manages our DEV and PROD builds and runs the webpack-dev-server.
Proper JS documentation is created with every Production build of the app so there is no excuse for writing sloppy code.
Your front-end templating apprach might be different, but for me, including bootstrap means building in a very solid foundation.
Once compiled and deployed, your app can be accessible on Github Pages. This one is.
Webpack is used to do all the "Behind The Scenes" work. Minifying, uglifying, building, cleaning, managing and more is done through Webpack plugins and loaders
jQuery is enabled through one of Webpack plugins. I don't remember a project where I didn't want to include this 'Swiss Knife' library in my app.
This is a wildcard I'm experimenting with recently. Still trying to incorporate this neat library into my workflow.
In order to fully understand of what this Webpack template is and what it does, I would suggest heading to the repo page and cloning the code. Once you have it on your machine, read the README.md file to learn how to build the app. If you aren't interested in how this template is set up, you can head directly to the /src folder and start modifying the code. Remember that the /src folder is the only one you should use to write code. All files in the /dist folder are minified and the folder is re-created every time you run the -npm run dev- command.
If your tendency is to try to hack something together and to skip code comments in order to make a dirty mvp, you're like me. In many cases, the reasoning is that comments can be added later- once the project is over. However, if my starting point is already configured to properly read my code comments and turn them into a proper documentation, I'm more likely to put some effort and include commenting in my workflow. With this template, you get proper documentation for free and you can check out an example here You might notice that the README.md file is exactly the same as the index.html file for the documentation. That is intentional, letting you include most important information about your Repo whithin the documentation pages.