Files
ihasmail-inbuxa/web/src/lib/mailbox/__tests__/emptyFolder.test.ts
T
jcoffey-dev bd6a605d61 Group six more clusters out of web/src/lib
Takes the flat module count from 66 to 42, continuing what admin/ and
calendar/ started.

  lib/mailbox/  archiveDate, emptyFolder, folderMove, labelTree,
                mailboxName, mailboxRoute
  lib/sieve/    sieve, sieveApply, sieveFolders
  lib/input/    keyboard, swipe, touch, listSelection, dropUpload
  lib/notify/   notify, webpush, webpushEnable
  lib/sw/       swCache, swFacts, staleBuild
  lib/text/     html, markdown, text, emlName

FOUR THINGS THE FILENAMES GET WRONG, each checked by reading the file
rather than trusting what it is called:

  - appFolder is not a mailbox. It is the `ihasmail` folder in JMAP
    *Files*, where the client keeps signature images and synced settings.
    It stays flat.
  - format holds no formatting of text. It re-exports the date and clock
    formatters, so it belongs with dates/datetime, not with text/.
  - preview is the file viewer deciding what it can show without
    downloading, and source is where to point someone asking for this
    instance's AGPL source. Neither is about text.
  - notify is not Web Push. It is the tab title, the favicon badge and
    the new-mail sound -- in-app notification, which is why it sits with
    webpush rather than under sw/ with the service worker's own concerns.

threadScroll stays flat too: it decides where a conversation opens, which
is view state rather than a gesture, and input/ is honest only if
everything in it interprets something the reader did.

No behavior change. Almost every reference was on the @/ alias; eight
relative imports in files that did not move, or that moved away from a
sibling, needed rewriting by hand.
2026-09-15 23:17:50 -07:00

42 lines
1.7 KiB
TypeScript

import { describe, expect, it } from "vitest";
import { canEmpty, emptyLabel } from "@/lib/mailbox/emptyFolder";
import type { MailboxRole } from "@/jmap/types";
/**
* Emptying destroys everything in a folder in one action, with no undo and no
* trip through Deleted Items. Which folders may be emptied is therefore a
* safety property, not a presentation one — the store enforces it too, and
* these pin the half the menus decide.
*/
describe("which folders may be emptied", () => {
it("allows exactly Deleted Items and Junk Mail", () => {
expect(canEmpty("trash")).toBe(true);
expect(canEmpty("junk")).toBe(true);
});
it("refuses folders holding mail someone meant to keep", () => {
const keep: MailboxRole[] = ["inbox", "archive", "sent", "drafts", "all", "flagged", "important", "subscribed"];
for (const role of keep) expect(canEmpty(role), String(role)).toBe(false);
});
it("refuses a plain folder, which has no role at all", () => {
expect(canEmpty(null)).toBe(false);
expect(canEmpty(undefined)).toBe(false);
});
});
describe("what the action is called", () => {
it("says what it does to spam, rather than naming the folder", () => {
// "Delete all spam" is what this is called everywhere else; "Empty Junk
// Mail" would be accurate and still leave people hunting for it.
expect(emptyLabel({ name: "Junk Mail", role: "junk" })).toBe("Delete all spam");
expect(emptyLabel({ name: "Spam", role: "junk" })).toBe("Delete all spam");
});
it("names the folder for Deleted Items, whatever the server calls it", () => {
expect(emptyLabel({ name: "Deleted Items", role: "trash" })).toBe("Empty Deleted Items");
expect(emptyLabel({ name: "Trash", role: "trash" })).toBe("Empty Trash");
});
});