Consistent scripts to rule them all

Last updated:

|Edit this page|

PostHog has 235 (at the time of writing) public repositories. Each of these repositories has a unique way to get the project up and running locally. To limit the friction of this we adapt GitHub's approach of scripts to rule them all. As they say:

Being able to get from git clone to an up-and-running project in a development environment is imperative for fast, reliable contributions.

Not every repository will need every script. Some repositories will need scripts custom to the environment (for example, make files). That's all fine. The goal is to have a baseline set of scripts that we can use to get a development environment up and a known location to look for those scripts.

Standard scripts at PostHog

When starting a new project, create a bin directory and include the following scripts (when relevant):

  • bin/setup - Install or upgrade dependencies (Ex. npm packages, brew packages, etc. Usually run once after cloning the repository and occasionally to upgrade packages).
  • bin/update - Updates dependencies after a pull. This could simply call bin/setup.
  • bin/build - Build the project, for projects that are compiled such as C#, Java, etc.
  • bin/start - Start the project. For SDKs, this might start an example server.
  • bin/test - Run tests (Ex. npm test, bundle exec rspec, etc.). Also includes linting, formatting, etc.
  • bin/fmt - Optional: Format/lint code. This can be called by test.
  • bin/docs - Optional: Generate documentation artifacts like API and SDK references.

Warning: Some environments add bin to the .gitignore file by default because that's where they compile binaries to.

Questions? Ask Max AI.

It's easier than reading through 678 pages of documentation

Community questions

Was this page useful?

Next article

Support hero

Every week, one person in each engineering team is designated the Support Hero. If this is you this week, congratulations! As Support Hero, your job is to investigate and resolve issues reported by customers. A single case of suspicious data or a show-stopping bug can really undermine one's confidence in a data product, so it's important that we get to the bottom of all issues. One of the many awesome things about PostHog is that support is being dealt with by engineers and they ship fixes and…

Read next article