|
| 1 | +# Repository Guidelines |
| 2 | + |
| 3 | +This guide explains how to contribute to **@datastax/langflow‑client**. Keep it short, follow the practices below, and you’ll help keep the repo healthy. |
| 4 | + |
| 5 | +## Project Structure & Module Organization |
| 6 | + |
| 7 | +``` |
| 8 | +src/ # TypeScript source code |
| 9 | +src/test/ # Unit tests (TS, run via `npm test`) |
| 10 | +dist/ # Compiled JavaScript (created by `npm run build`) |
| 11 | +``` |
| 12 | + |
| 13 | +Public APIs are exported from `src/index.ts`, `src/consts.ts`, `src/errors.ts`, `src/flow.ts`, `src/flow_response.ts` and `src/upload_response.ts`. Tests import from the same module paths used by consumers. |
| 14 | + |
| 15 | +## Build, Test, and Development Commands |
| 16 | + |
| 17 | +```bash |
| 18 | +npm run build # Transpile TypeScript to `dist/` |
| 19 | +npm run build:clean # Remove dist/ directory |
| 20 | +npm run build:watch # Watch for changes and transpile |
| 21 | +npm run build:check # Run the compiler to check types, but not transpile |
| 22 | +npm run lint # ESLint lint check |
| 23 | +npm run format # Prettier format source files |
| 24 | +npm run format:check # Check to see if source files require formatting |
| 25 | +npm test # Run unit tests with tsx |
| 26 | +npm run test:coverage # Generate coverage report in `coverage/` |
| 27 | +``` |
| 28 | + |
| 29 | +The project uses **TypeScript**, **ESLint**, and **Prettier** for coding style. |
| 30 | + |
| 31 | +## Coding Style & Naming Conventions |
| 32 | + |
| 33 | +- **Indentation**: 2 spaces (Prettier default). |
| 34 | +- **File names**: lower‑case with hyphens (e.g., `flow_response.ts`). |
| 35 | +- **Exports**: prefer named exports; keep modules small. |
| 36 | +- **Constants**: UPPER_SNAKE_CASE (e.g., `const MAX_RETRY = 5`). |
| 37 | +- **Functions/Methods**: camelCase. |
| 38 | +- Format with `npm run format` before committing. |
| 39 | + |
| 40 | +The ESLint configuration is in `eslint.config.mjs` and rules are pulled from `@eslint/js` + `typescript-eslint`. |
| 41 | + |
| 42 | +## Testing Guidelines |
| 43 | + |
| 44 | +- Tests live in `src/test/`. |
| 45 | +- Test files end with `.test.ts` (e.g., `flow.test.ts`). |
| 46 | +- Run tests locally with `npm test`. |
| 47 | +- Coverage can be produced by `npm run test:coverage`. |
| 48 | +- Aim for >80 % coverage; new features should add tests. |
| 49 | + |
| 50 | +## Commit & Pull Request Guidelines |
| 51 | + |
| 52 | +- Follow **Conventional Commits**: `feat:`, `fix:`, `refactor:`, `docs:`, `chore:`. |
| 53 | +- Commit titles should be short (<50 chars) and describe the change. |
| 54 | +- Pull Request titles should start with the same type (e.g., `feat: add upload helper`). |
| 55 | +- Include a brief description of the change in the PR body. |
| 56 | +- Reference any related issue with `Closes #123`. |
| 57 | +- If the PR touches the public API, document the change in the README or CHANGELOG. |
| 58 | +- Add screenshots or examples only when the PR adds UI or demo files. |
| 59 | + |
| 60 | +## Security Tips |
| 61 | + |
| 62 | +- Never commit credentials or API keys to the repository. |
| 63 | +- Use environment variables or a `.env` file (excluded from `git`) when running locally. |
| 64 | +- When distributing the package, the `apiKey` is always sent as a bearer token or `x-api-key` header – no credentials are stored in the library. |
| 65 | + |
| 66 | +## Architecture Overview |
| 67 | + |
| 68 | +The library is a thin wrapper around the **Langflow** HTTP API. |
| 69 | + |
| 70 | +``` |
| 71 | ++-------------+ +-------------------+ +----------+ |
| 72 | +| User Code | => | LangflowClient API | => | Langflow | |
| 73 | +| (module) | => | (HTTP requests) | => | (server)| |
| 74 | ++-------------+ +-------------------+ +----------+ |
| 75 | +``` |
| 76 | + |
| 77 | +1. **`LangflowClient`** – handles configuration, request signing, and headers. |
| 78 | +2. **`Flow`** – provides high‑level methods (`run`, `stream`, `uploadFile`). |
| 79 | +3. **Response classes** (`FlowResponse`, `UploadResponse`) parse and surface |
| 80 | + data in a user‑friendly way. |
| 81 | + |
| 82 | +The flow follows the standard **request → response** pattern, optionally |
| 83 | +streaming JSON using NDJSON for efficient large payloads. |
| 84 | + |
| 85 | +## Contribution Checklist |
| 86 | + |
| 87 | +Before submitting a pull request, run the following to ensure code quality: |
| 88 | + |
| 89 | +```bash |
| 90 | +npm run format:check # Verify files are properly formatted |
| 91 | +npm run lint # Catch linting errors |
| 92 | +npm test # Ensure all unit tests pass |
| 93 | +``` |
| 94 | + |
| 95 | +If all checks pass, you may submit your PR with a descriptive title and body. |
| 96 | + |
| 97 | +--- |
| 98 | + |
| 99 | +Happy coding! If you have questions, open an issue or contact the maintainer. |
0 commit comments