🚨 Shai-Hulud Strikes Again:834 Packages Compromised.Technical Analysis β†’
Socket
Book a DemoInstallSign in
Socket

@evdy-consumer/dailyom-suite-services

Package Overview
Dependencies
Maintainers
1
Versions
95
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@evdy-consumer/dailyom-suite-services

This library provides various services for the DailyOM Suite, including requests to internal API's and integrations with third-party APIs like Stripe and Thinkific. It is designed to be used across different applications within the suite, ensuring a consi

npmnpm
Version
0.0.15
Version published
Weekly downloads
200
1.01%
Maintainers
1
Weekly downloads
Β 
Created
Source

@dailyom-suite/services

This library provides various services for the DailyOM Suite, including requests to internal API's and integrations with third-party APIs like Stripe and Thinkific. It is designed to be used across different applications within the suite, ensuring a consistent and efficient way to handle data fetching and processing

This library was generated with Nx

Command used to generate this library:

nx generate @nx/js:lib libs/services

Lib structure

The services inside this library are organized into different directories based on their functionality. The general structure is as follows:

libs/services
β”œβ”€β”€ src
β”‚   β”œβ”€β”€ lib
β”‚   β”‚   β”œβ”€β”€ internal
β”‚   β”‚   β”‚   β”œβ”€β”€ private
β”‚   β”‚   β”‚   └── public
β”‚   β”‚   └── third-party
β”‚   └── index.ts
└── README.md

Each new service should be added under the src/lib directory, either in the internal or third-party subdirectories, depending on whether it interacts with internal APIs or third-party services. Additionally we have agreed on structuring each service with a consistent CRUD pattern based on the resource it interacts with. This means that each service should have methods for creating, reading, updating, and deleting resources as applicable.

Public vs Private

The internal directory is further divided into private and public subdirectories:

  • Private: Contains services that are not intended for public use and are used internally within the application. Additionally, these services are protected by authentication and authorization mechanisms.
  • Public: Contains services that are intended to be used without authentication, such as public APIs or endpoints that do not require user credentials.

Example structure for a user service:

  /src
  └── /lib
      └── /internal
          └── /private
              └── /users
                  β”œβ”€β”€ get.ts
                  β”œβ”€β”€ post.ts
                  β”œβ”€β”€ update.ts
                  └── delete.ts

If there is a need for a nested service it can be placed in a subdirectory within the main resource directory.

Example structure for a user id service:

  /src
  └── /lib
      └── /internal
          └── /private
              └── /users
                  β”œβ”€β”€ get.ts
                  β”œβ”€β”€ post.ts
                  β”œβ”€β”€ update.ts
                  └── delete.ts
                    └── /id
                        β”œβ”€β”€ get.ts
                        β”œβ”€β”€ update.ts
                        └── delete.ts

Add a new service

To add a new service to this library, follow these steps:

  • Create a new directory under src/lib/internal or src/lib/third-party based on the type of service.
  • Inside the new directory, create a file for each method you want to implement (e.g., get.ts, create.ts, update.ts, delete.ts).
  • Implement the logic for each method in its respective file.
  • Export the methods from the src/lib/index.ts file to make them available for import in other parts of the application.
  • Run the following command to ensure the new service is properly built and ready for use:
nx build services

Validation

To ensure the data integrity and correctness of the payloads sent to the services, we use Zod for schema validation. Each service should have a corresponding schema defined in the @lib/services/schemas library. For example, if you are creating a service for user login, you would define a schema in the @lib/services/schemas library and use it in your service like this:

/schemas/login.schema.ts

import { z } from 'zod/v4';

export const loginSchema = z.object({
  email: z.email(),
  password: z.string().min(8, 'Password must be at least 8 characters long'),
});

export type LoginSchema = z.infer<typeof loginSchema>;

/lib/.../login/post.ts

import { zodValidate } from '@lib/services/utils';
import { loginSchema, LoginSchema } from '@lib/services/schemas';
export const login = async (payload: LoginSchema) => {
  const validatedPayload = zodValidate(loginSchema, payload);

  const response = await fetch('example-url', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(validatedPayload),
  });

  return response.json();
};

Running unit tests

Run nx test services to execute the unit tests via Jest.

Usage

To use the services provided by this library, you can import them in your application code as follows:

import { createUser, getUsers } from '@evdy-consumer/dailyom-suite-services';

CI

PRs that contain changes to services will run tests and builds to ensure project structure is adhered to.

FAQs

Package last updated on 04 Nov 2025

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts