- Created libs/legacy-api with description and platform team ownership
- Updated tsconfig.base path mapping and CODEOWNERS
- npm install changes in package-lock from generator
feat(api): add minimal ApiClient and HttpOperations type with lifted core methods (send, fetch/nativeFetch, token helpers, error handling)
feat(api): include prerelease flag header in ApiClient headers to match ApiService behavior
refactor(api): type logoutCallback param as LogoutReason to mirror ApiService
chore(api): remove unused HttpOperations import from abstraction
refactor(api): rename api-client.ts to api.service.ts and update barrel/spec imports
chore(api): restore comments and constructor parity with common ApiService (device field, directory traversal note, unauthenticated header rationale)
angular: provide TokenProvider -> TokenProviderService; convert TokenProvider to abstract class for DI token; no cycles with @bitwarden/api
feat(token-provider): add TokenProvider abstraction and export from index
feat(token-provider): implement TokenProviderService (lift-and-shift of token logic from ApiService)
feat(token-provider): add prerelease header parity and flags import
feat(token-provider): export TokenProviderService from index
* feat(nx): add basic-lib generator for streamlined library creation
This adds a new nx-plugin library with a generator for creating "common" type
Bitwarden libs. It is set up to accept a lib name, description, team, and
directory. It then
- Creates a folder in the directory (default to libs)
- Sets up complete library scaffolding:
- README with team ownership
- Build, lint and test task configuration
- Test infrastructure
- Configures TypeScript path mapping
- Updates CODEOWNERS with team ownership
- Runs npm i
This will make library creation more consistent and reduce manual boilerplate setup.
The plugin design itself was generated by `npx nx g plugin`. This means we
used a plugin to generate a plugin that exports generators. To create our
generator generator, we first needed a generator.
* fix(dirt/card): correct tsconfig path in jest configuration
Fix the relative path to tsconfig.base in the dirt/card library's Jest config.
The path was incorrectly using four parent directory traversals (../../../../)
when only three (../../../) were needed to reach the project root.
* chore(codeowners): clarify some nx ownership stuff
