Project file hierarchy

Constants

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

Utils

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.

Services

Place services in to directory ./services.

Styles

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.

Components

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.

Types

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 NAME.hg.fi, 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.