Project file hierarchy


Place constants in to directory ./constants.

For example:

  • CSS Class names to ./constants/className.ts
  • Translation tokens to ./constants/translation.ts
  • Environment variables (e.g. build parameters) to ./constants/environment.ts
  • Global constants for frontend to ./constants/frontend.ts
  • Backend specific constants like URLs to ./constants/backend.ts


Place utils in to directory ./utils.

Sometimes it's ok to place them also in ./services. Just make sure you use clear naming as FooUtils.


Place services in to directory ./services.


Place shared styles -- e.g. variables and themes -- in to directory ./styles.

Note! You should place other styles (usually related to layout) directly beside the component in question.


Place components in to ./component/componentName/componentName.tsx and ./component/componentName/componentName.scss.

The name should always have the same name as the class/function.

The SCSS for this component should be located in the same directory and imported from the componentName.tsx file.

Use only CSS classes. Use of ids will make is more likely that you need to do use !important.


Place types to subdirectory ./types in the folder where the type should be used and named by the type's name.

E.g. if that's only internal type for a service, use services/types/fooEnum.ts.

If it's just for a component, use components/componentName/types/fooEnum.ts.

If it's a global type, use types/fooEnum.ts.

Shared modules

If your project has shared code between multiple parts (eg. backend and frontend), create a new git submodule shared between these projects.

Place files related to this module to us a domain specific naming. E.g. we own the address, so our files go under src/fi/hg/NAME.

We also use the same format for repository names, eg. we'll name it as @heusalagroup/fi.hg.NAME. Note, this makes it much easier for people to fork your repository as it will not conflict with other possible repositories in their Github.

You may also use {types,components,utils,services} naming under this submodule if it suits you.

Sometimes these subdirectories could also be their own git submodules. We do this with our UI related modules. That way we can work with different styles in different branch without changing other parts of the system.