⚠️ The package is deprecated. See SPRO instead.
This article is the very first article in a series about Starter Project, a set of the latest best practices packed in Gulp tasks. In this article, I am going to explain the idea behind this project, how it could help you on your project and how to use it.
Every project has its environment. Switching between projects means switching environments. Switching environments means remembering commands for running project tasks, like Gulp or webpack. But too often commands are forgotten. This scenario happens to me daily, even when working on similar projects.
Consider two different projects. First is custom WordPress theme development, second is Middleman blog. Both projects use Gulp task runner to compile and optimize assets. Setting up Gulp tasks for either project is time-consuming work. And every project has its architecture which disables a developer to copy Gulp tasks from one project to another without spending the time to reconfigure every Gulp task individually.
Working on a project without a coding convention could be a nightmare. Git conflicts on every merge, endless discussion about tabs versus spaces, ugly and inconsistent code are just some of the problems that could emerge as a consequence.
The package is available on npm. You could find instructions for the installation in official documentation. Once installed, you will have the copy of the package’s website for the Starter project. It could be a good starting point for your new project.
Starter Package is also a static page generator, a very rudimental one. The original website is built using Starter Project and hosted on Netlify. It is very fast, see the PageSpeed Insights and WebPageTest scores.
The package should be used as a development dependency. That will allow you to update the package and maintain your project more efficiently.
Starter project has three different Gulp commands for different environments:
gulp distfor a development build,
gulp docsfor documentation build, and
gulpfor a production build.
With Starter Project you get the architecture for:
- images (.png, .jpg, .svg),
- and more.
You could find all assets in
new_src folder. Once you run one of the build commands,
new_dist folder will be created with compiled static contents.
Starter Project is configurable and should be able to run in every project, no matter the architecture. The main configuration file could be found in the root of the project,
config.json. For every task, there is an option
run. If set to true, the task will run. For example, you could turn off
penthouse, a library for generating Critical CSS.
Read more about configuration here.
I mentioned Critical CSS in the previous section. Starter Project has other great features.
Pug is default template engine. Markdown is also supported via Pug filter jstransformer-markdown-it. I should consider adding support for more template engines if interest is shown.
Starter Project supports ES6 via babel plugin. You will find scripts for deferred loading of CSS files (use it in combination with Critical CSS) and for loading fonts with Critical FOFT method.
If you are not using a third-party service for hosting images, then Starter Project could optimize your images. Starter Project supports
There are other goodies, like Browser-sync, Favicons, Sourcemaps, Gzip, Linters, Standards, editorconfig, and more. I will try to document everything and write new articles about these, too. Stay tuned!
I have used Starter Project on several different projects so far.
- Han Han Xue website - a website with a blog for Han Han Xue, a Designer and FX Technical Director from Montreal, Canada. The site runs on Middleman.
- Irina & Matej website - a website for Irina and Matej, wedding and portrait photographers based in Croatia. The site runs on WordPress.
- Silvestar Bistrović website - a personal website with a blog. The site runs on Hexo.
- Starter Project website - a website for Starter Project. The website runs on Starter Project only.
Starter Project is not conceived as a strict set of rules. This package should be configured to fulfill every project specification; you could propose new features, fork the repository or turn off some of the tasks in the config file.