# Repository Guidelines

## Project Structure & Module Organization
- `src/tweekit.js` hosts the widget class, Croppie integration, and UI handlers; extend this module for widget behavior.
- `src/constants.js` centralizes defaults and enumerations—extend these rather than hard-coding values in the widget.
- `config/` holds webpack environment definitions for development, QA, and production outputs; adjust API targets here when changing back-end endpoints.
- Build artifacts land in `_Output/tweekit/` for local runs and `dist/` for npm bundles; never edit generated files manually.

## Build, Test, and Development Commands
- `npm install` pulls all widget and build dependencies; rerun after updating `package.json`.
- `npm test` launches `webpack-dev-server` against the development config, suitable for manual verification in a browser.
- `npx webpack --env environment=production` produces a release build under `_Output/tweekit/release/` for quick smoke testing.
- `npx webpack --env environment=production-npm` emits the distributable UMD bundle in `dist/` for npm publishing.

## Coding Style & Naming Conventions
- Favor ES6 modules, 4-space indentation, and descriptive camelCase identifiers as seen in `src/tweekit.js`.
- Keep widget state on the class instance (`this._property`) and expose new behavior through methods or getters.
- Mirror existing string quoting (double quotes for DOM work, single quotes for imports) to avoid noisy diffs.
- Run the webpack build before submitting so Babel surfaces syntax issues early.

## Testing Guidelines
- Automated tests are not yet in place; rely on `npm test` to exercise flows in the browser and verify crop interactions.
- Document manual test cases in the PR description, especially for upload and crop flows.
- When adding logic-heavy utilities, consider introducing unit tests so future contributors can validate without the UI.

## Commit & Pull Request Guidelines
- Craft concise, present-tense commit messages ("add proportional crop resizing") in the style of the existing history.
- Group related changes per commit and avoid mixing formatting updates with feature work.
- Pull requests should outline motivation, highlight risky areas, list manual verification steps, and link to any product or Jira tickets.
- Include screenshots or short clips for UI changes so reviewers can gauge visual impact before pulling locally.

## Security & Configuration Tips
- Never hard-code credentials; update DefinePlugin entries in `config/*.js` for host and protocol selection.
- Review generated bundles before publishing to ensure no debug logging or secrets leak into `dist/`.
- Keep dependencies current and run `npm audit` when updating to catch upstream vulnerabilities.