We have a strict dependency policy for security and stability purposes.
Only necessary dependencies are accepted.
These must have a clear purpose for the project -- especially from external sources like the NPM.
Our own modules are published as a build-time git submodules and are not available from the NPM.
|@heusalagroup/fi.hg.core||Full Stack||General purpose utilities for logging, events, HTTP requests, etc.|
|@heusalagroup/fi.hg.matrix||Full Stack||Our extremely lightweight Matrix library which works also on embedded systems (OpenWRT)|
The UI is split to three separate modules with an index project at @heusalagroup/fi.hg.ui:
|@heusalagroup/fi.hg.ui.styles||Frontend||Frontend styles library|
|@heusalagroup/fi.hg.ui.components||Frontend||Frontend components library|
Note! The UI modules include code that's not considered stable at the moment.
Accepted external libraries
|Project Name||Package Name||Scope||Purpose|
||Full Stack||Testing framework|
||Frontend||User interface library for the Web|
|Create React App||
||Frontend||Environment tools for React development|
||Frontend||Library to implement routes on the client side|
||Frontend||Compiles SCSS to CSS|
|React Router Hash Link||
||Frontend||Enables hash based links in the app. You should prefer not to use hash based links, though.|
||Backend||Enables TypeScript support for NodeJS|
It's also acceptable to install
@types/FOO dependencies for these projects to add the TypeScript support.
For specific purposes it's acceptable to introduce a new library.
You should consult the lead developer in that case.
Some general points to consider while choosing a library:
- It should have a MIT license and other compatible ones
- Prefer zero dep libraries. The module shouldn't have too many dependencies.
- Prefer build time only libraries. We want to have the freedom to compile our code into single small deployable bundle which doesn't have too many dependencies.