@exodus/analytics-validation
v2.47.1
Published
JSON schemas for analytics events, to prevent sensitive data from being sent up to the infamous cloud
Downloads
15,937
Readme
@exodus/analytics-validation
Why
This helps prevent that we do not accidentally collect any sensitive and/or private information, therefore all events must pass a validation layer.
Examples of what could go wrong:
Development
Do I need to add a new schema?
flowchart TD
Title(Adding a new telemetry event) --> A
A{Does your event\nhave properties?}
A -->|Yes| C
A -->|No| B
B(You're done!)
C{Does it only require\n the 'origin' property?}
C -->|Yes| B
C -->|No| E[Generate a new JSON Schema: \nyarn generate analytics-validation]
E --> D[Adjust the schema and tests]
D --> B
JSON Schema Development
To add a new schema run
yarn generate analytics-validation
in the project root. The CLI tool will ask you for all details needed. Once the schema is created, make sure to
- Before adding a new schema, double check if a subdirectory (essentially an event domain, e.g.
dapps
) already exists in./src
. If not, you will have to come up with a subdirectory name during the next steps; - Fill the schema with the expected properties and their types. The property names must be in the snake_case (e.g.
expected_property
); - Fix the generated unit test as it will be intentionally failing;
- Add your own test cases to ensure the schema works properly before merging the PR and publishing a new version.
List of string formats
Schemasafe ships with a bunch of default formats, you can find the implementation of these here!
- hostname
- uuid
- date
- time
- date-time
- duration
- ipv4
- ipv6
- uri
- uri-reference
- uri-template
- alpha
- alphanumeric
- base64
- hex-digits
- hex-digits-prefixed
- hex-bytes
- hex-bytes-prefixed
- json-pointer
- relative-json-pointer