-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PM-328] Move exporter to tools #5070
Conversation
Create package.json Create tsconfig Create jest.config Extend shared and root tsconfig and jest.configs Register with eslint
Move exportService (abstraction and impl) into libs/exporter Refactored exportService to be split into vault-export and event-export Created barrel-files for both exports Moved export.service.spec.ts into vault-export Created an export-helper, which helps build the filename (extract method refactor from ExportService)
Moved components Updated imports in jslib-services.module and jslib.module
Move export.component into tools-subfolder
Move export.command into tools-subfolder
Move export.component into tools-subfolder
…-328-move-exporter-to-tools
…-328-move-exporter-to-tools
Reponse models in common rely on export models which are in libs/exporter, which relies on common
export { CardExport } from "./card.export"; | ||
export { CipherWithIdExport } from "./cipher-with-ids.export"; | ||
export { CipherExport } from "./cipher.export"; | ||
export { CollectionWithIdExport } from "./collection-with-id.export"; | ||
export { CollectionExport } from "./collection.export"; | ||
export { FieldExport } from "./field.export"; | ||
export { FolderWithIdExport } from "./folder-with-id.export"; | ||
export { FolderExport } from "./folder.export"; | ||
export { IdentityExport } from "./identity.export"; | ||
export { LoginUriExport } from "./login-uri.export"; | ||
export { SecureNoteExport } from "./secure-note.export"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't these be moved to the export module? Feels like internal implementation details for the export lib.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed previously with @MGibson1 and you, ideally these would move over into the export-package, but this would create a weird reference for the CLI which extends the export-models. As we currently do not plan to change this, due to the low-benefit to high work ratio, I'm proposing to keep them in libs/common/models/export.
@@ -0,0 +1,6 @@ | |||
import { EventView } from "@bitwarden/common/models/view/event.view"; | |||
|
|||
export abstract class EventExportServiceAbstraction { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we consider event exporters part of the export module? Those feel like a separate domain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I split it off, as it previously was part of the export.service. Which it definitely shouldn't be. Currently the event-export is only possible in the web-vault and could be moved their, if desired.
On the other hand, it might be benefical to have it in a lib to be also used in the CLI. This has not been discussed with Product, but it could be useful to have a CLI way of exporting and piping the output into a different tool (log-analyzer)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was more thinking that libs/exporter
should encompass the vault exporting capabilities, and events belongs to another module.
…-328-move-exporter-to-tools
…-328-move-exporter-to-tools
…-328-move-exporter-to-tools
@@ -1,7 +1,7 @@ | |||
import { FieldType, LinkedIdType } from "../../enums"; | |||
import { EncString } from "../../models/domain/enc-string"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import { EncString } from "../../models/domain/enc-string"; | |
import { EncString } from "../domain/enc-string"; |
@@ -1,7 +1,7 @@ | |||
import { UriMatchType } from "../../enums"; | |||
import { EncString } from "../../models/domain/enc-string"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import { EncString } from "../../models/domain/enc-string"; | |
import { EncString } from "../domain/enc-string"; |
@@ -0,0 +1,6 @@ | |||
import { EventView } from "@bitwarden/common/models/view/event.view"; | |||
|
|||
export abstract class EventExportServiceAbstraction { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was more thinking that libs/exporter
should encompass the vault exporting capabilities, and events belongs to another module.
|
||
export class EventExportService implements EventExportServiceAbstraction { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export class EventExportService implements EventExportServiceAbstraction { | |
@Injectable() | |
export class EventExportService implements EventExportServiceAbstraction { |
Type of change
Objective
Re-structure code in preparation for code ownership of the tools-team
Extract common/export.services and related files into their own lib -> libs/exporter
Code changes
Before you submit