Tonight we’ll look at how “that other” folder in your webapp could be structured. Many codebases I’ve been through seems to handle this location as the junkyard of the application, it contains an unstructured collection of JS, CSS and images mixed together in various ways. The folder itself can be called anything, but I usually want to make a distinction that nowadays our frontend is a separate application from our Java backend. That’s why I usually name this folder as “app”.
Let’s take a look how it looks and see what files and folders our application would contain:
1 2 3 4 5 6 7 8 9
app / dist / stylesheet / src / test package.json .babelrc .eslintrc build.js
OK, looks straightforward enough.
- Folder containing minified bundles meant to be distributed when deploying the web application
- Contains all JS files starting with runner and application entry point
- Depending on how you want to structure your application contains folder per view and that folder contains an index.js as an entry point for the sources associated with that view. By view in here I mean usually a single individual part of our multi-page single-page-application
- Also has util/common/etc. folders for shared code
- For css, less and sass files. This folder contains unminified sources that will be built and stored in the /dist folder for publishing.
- for… wait for it… images
- dependencies loaded by node.js, think of .m2 folder. This should be excluded from the packaging when building the web application and gitignored
- Root level files:
- NPM config file, the heart of the application
- Contains dependency lists, startup scripts and information about the application
- Usual entry point for the frontend part think this as an equivalent to pom.xml * .babelrc
- Configuration file for babel.
- It is time to jump into ES2015/ES2016 train. There is no way around it * .eslintrc:
- ES Lint config file for our project
- Contains configurations for static analysis to be run to check our code quality and guard it against quality lapses * build.js
- This is our build file containing all scripts to compile, build, transpile, run tests, analyze etc. our frontend codebase
Alright, that’s a good start to think about frontend code as an invidual application. Next time we will dive deeper into the build.js file. That will be our workhorse when we will be developing frontend code. There are few good choices to choose from, we’ll take a look at Gulp first and then transform more and more towards webpack world.