chore(deps): bump jira.js from 5.4.0 to 6.2.0

[dependabot]

Bumps jira.js from 5.4.0 to 6.2.0.

Release notes

Sourced from jira.js's releases.

v6.2.0

Avatars moved bytes in both directions and the specification described both as JSON, so neither direction worked. Reading an image threw before the response reached the caller; uploading one had no way to send an image at all. Both are fixed here, along with two column endpoints broken by the same reading of the same specification.

Bug Fixes

• getAvatarImageByID, getAvatarImageByType and getAvatarImageByOwner return the image. All three were generated with StreamingResponseBodySchema — the specification's StreamingResponseBody, an object with no properties — so a response arriving as image/png or image/svg+xml was reported as SchemaMismatchError: Expected a JSON response to validate against the schema. There was no input for which they could succeed. They now return a Blob. Fixes #434.

  A Blob rather than the bytes alone, because the content type cannot be worked out from the request: the same avatar URL answers with SVG for a system avatar and PNG for an uploaded one, and format is optional. image.type is the content type, await image.arrayBuffer() the bytes, and new Response(image) passes it straight to a browser. In v5 this was AvatarWithDetails — { avatar, contentType }; the two fields are now one value.

  Attachment downloads are unchanged. getAttachmentContent and getAttachmentThumbnail still return the bytes, because an attachment already carries its mimeType and filename in its metadata.

• storeAvatar, createProjectAvatar and createIssueTypeAvatar accept an image. Their request body was generated as Record<string, any> — an object of arbitrary keys — because Atlassian declares it under a wildcard media type with an empty schema. It is now a Blob:

  await jira.avatars.storeAvatar({
    type: 'project',
    entityId: project.id,
    size: 48,
    body: new Blob([bytes], { type: 'image/png' }),
  });

  The Blob carries the content type the endpoint reads the image by; fetch takes the header from it, so nothing is passed alongside it and nothing can contradict it. The three calls also send X-Atlassian-Token: no-check, which Jira requires — without it the upload is refused outright, with it and no content type the image is rejected as an unsupported format. Both were verified against a live site.

• setUserColumns and setIssueNavigatorDefaultColumns take the columns. Both declare a ColumnRequestBody reference under a wildcard media type and nowhere else; only application/json was read, so the reference was missed and the body degraded to the same shapeless object. They now take columns: string[], like setColumns on a filter already did:

  await jira.users.setUserColumns({ columns: ['summary', 'status'] });

Types

• Those three methods are typed Promise<Blob>, where they were Promise<StreamingResponseBody>. Nothing that compiled against the old type can have been working — the call threw before returning — so the compiler pointing at these lines is the first honest signal about them. StreamingResponseBody itself is still exported; nothing else referenced it.

• BlobSchema is exported from jira.js/core, beside BufferSchema. It marks an endpoint whose response is bytes with a content type worth keeping; the client reads such a response with response.blob() rather than parsing it as JSON.

• The three upload bodies are typed Blob, where they were Record<string, any>. No call could have worked: the endpoints refuse a request without the XSRF header, which the old shape had no way to send.

• setUserColumns and setIssueNavigatorDefaultColumns take columns: string[] in place of body. Unlike the avatar uploads, these two had a working form — { body: { columns: [...] } } reached Jira intact — so a call written that way needs the one-line change. { body: [...] }, the other reading the old type invited, was answered with 400.

• The agile models point at their nested shapes instead of repeating them. A board's admins.users was written out in full in each of the models that carried a board, and the same held for changelog histories, column statuses and issue fields across twenty-one others. They now reference UserSchema, GroupSchema, BoardLocationSchema, RelationSchema, ChangelogSchema and the rest, each of which was exported already and describes the identical shape, field for field and constraint for constraint. Nothing validates differently, no description was lost, and every type is structurally what it was — a nested shape simply reports itself by name in an editor now, and the generated agile sources are a thousand lines shorter.

• toggleFeatures takes a described body. It was typed Record<string, any> — an object of arbitrary keys — because the shape was declared inline and had no name to point at; the operation's own boardId collides with the body's, so its fields cannot be spread the way rankIssues spreads its own. The body is now FeatureToggleRequest: { boardId?, enabling?, feature? }. A call already passing those three fields is unchanged.

• The agile model GetQuickFilter is deprecated in favour of QuickFilter. The two were the same six optional fields under two names, because the response was declared inline rather than by reference; it now resolves to the named schema, and getQuickFilter is typed Promise<QuickFilter>. The old name is still exported, still assignable and still the same type — an alias marked @deprecated, which an editor strikes through and which goes at the next major version. Nothing has to change today. The request parameter type of that name is untouched.

• Four orderBy parameters list the fields they sort by. getPrecomputations, getPrecomputationsByID, getTrashedFieldsPaginated and searchWorkflows were typed string while their own documentation named the fields — functionKey, used, created, updated for the precomputations, and so on. Fifteen other orderBy parameters carry the list in the specification and were generated from it all along; these four carried it only in prose. They are now typed the same way, sort prefixes included:

  await jira.jqlFunctionsApps.getPrecomputationsByID({ precomputationIDs: [...], orderBy: '-created' });

  As everywhere else, the type stays open — 'created' | '-created' | '+created' | ... | (string & {}) — so an editor suggests the documented fields and any other string still compiles.

• Five more agile models are deprecated in favour of the components they were copies of. createBoard and getBoard answer with Board, getAllBoards with PageBoard, getBoardByFilterId with PageBoardFilter, and getAllQuickFilters with PageQuickFilter. Each of those responses is declared inline in the specification, field for field the component sitting beside it, so the generator had nothing to name it after but the operation — and the component it duplicated went unused: no agile model referenced Board at all, while six of them wrote a board out in full. The retired names are still exported as @deprecated aliases of the new ones, assignable in both directions, and go at the next major version. Nothing has to change today.

  A board reports its type properly now, as a side effect worth naming. Board.type is 'scrum' | 'kanban' | 'simple' | (string & {}); every copy of it was a plain string, and since each of these methods returned a copy, the narrowing reached none of them. getBoard() and the boards inside getAllBoards().values carry it now.

• A page of things is typed Page<T>. Atlassian restates the pagination envelope once per item type — PageBoard, PageUser, PagedArticle, ninety-odd of them across the three APIs, identical but for what sits in values — and each generated a model of its own. So a page of boards and a page of users were two unrelated shapes with the same seven fields, and nothing said they were the same idea. Each API now has one Page<T>, and the endpoints answering with a page are typed with it:

... (truncated)

Changelog

Sourced from jira.js's changelog.

6.2.0

Avatars moved bytes in both directions and the specification described both as JSON, so neither direction worked. Reading an image threw before the response reached the caller; uploading one had no way to send an image at all. Both are fixed here, along with two column endpoints broken by the same reading of the same specification.

Bug Fixes

• getAvatarImageByID, getAvatarImageByType and getAvatarImageByOwner return the image. All three were generated with StreamingResponseBodySchema — the specification's StreamingResponseBody, an object with no properties — so a response arriving as image/png or image/svg+xml was reported as SchemaMismatchError: Expected a JSON response to validate against the schema. There was no input for which they could succeed. They now return a Blob. Fixes #434.

  A Blob rather than the bytes alone, because the content type cannot be worked out from the request: the same avatar URL answers with SVG for a system avatar and PNG for an uploaded one, and format is optional. image.type is the content type, await image.arrayBuffer() the bytes, and new Response(image) passes it straight to a browser. In v5 this was AvatarWithDetails — { avatar, contentType }; the two fields are now one value.

  Attachment downloads are unchanged. getAttachmentContent and getAttachmentThumbnail still return the bytes, because an attachment already carries its mimeType and filename in its metadata.

• storeAvatar, createProjectAvatar and createIssueTypeAvatar accept an image. Their request body was generated as Record<string, any> — an object of arbitrary keys — because Atlassian declares it under a wildcard media type with an empty schema. It is now a Blob:

  await jira.avatars.storeAvatar({
    type: 'project',
    entityId: project.id,
    size: 48,
    body: new Blob([bytes], { type: 'image/png' }),
  });

  The Blob carries the content type the endpoint reads the image by; fetch takes the header from it, so nothing is passed alongside it and nothing can contradict it. The three calls also send X-Atlassian-Token: no-check, which Jira requires — without it the upload is refused outright, with it and no content type the image is rejected as an unsupported format. Both were verified against a live site.

• setUserColumns and setIssueNavigatorDefaultColumns take the columns. Both declare a ColumnRequestBody reference under a wildcard media type and nowhere else; only application/json was read, so the reference was missed and the body degraded to the same shapeless object. They now take columns: string[], like setColumns on a filter already did:

  await jira.users.setUserColumns({ columns: ['summary', 'status'] });

Types

• Those three methods are typed Promise<Blob>, where they were Promise<StreamingResponseBody>. Nothing that compiled against the old type can have been working — the call threw before returning — so the compiler pointing at these lines is the first honest signal about them. StreamingResponseBody itself is still exported; nothing else referenced it.

• BlobSchema is exported from jira.js/core, beside BufferSchema. It marks an endpoint whose response is bytes with a content type worth keeping; the client reads such a response with response.blob() rather than parsing it as JSON.

• The three upload bodies are typed Blob, where they were Record<string, any>. No call could have worked: the endpoints refuse a request without the XSRF header, which the old shape had no way to send.

• setUserColumns and setIssueNavigatorDefaultColumns take columns: string[] in place of body. Unlike the avatar uploads, these two had a working form — { body: { columns: [...] } } reached Jira intact — so a call written that way needs the one-line change. { body: [...] }, the other reading the old type invited, was answered with 400.

• The agile models point at their nested shapes instead of repeating them. A board's admins.users was written out in full in each of the models that carried a board, and the same held for changelog histories, column statuses and issue fields across twenty-one others. They now reference UserSchema, GroupSchema, BoardLocationSchema, RelationSchema, ChangelogSchema and the rest, each of which was exported already and describes the identical shape, field for field and constraint for constraint. Nothing validates differently, no description was lost, and every type is structurally what it was — a nested shape simply reports itself by name in an editor now, and the generated agile sources are a thousand lines shorter.

• toggleFeatures takes a described body. It was typed Record<string, any> — an object of arbitrary keys — because the shape was declared inline and had no name to point at; the operation's own boardId collides with the body's, so its fields cannot be spread the way rankIssues spreads its own. The body is now FeatureToggleRequest: { boardId?, enabling?, feature? }. A call already passing those three fields is unchanged.

• The agile model GetQuickFilter is deprecated in favour of QuickFilter. The two were the same six optional fields under two names, because the response was declared inline rather than by reference; it now resolves to the named schema, and getQuickFilter is typed Promise<QuickFilter>. The old name is still exported, still assignable and still the same type — an alias marked @deprecated, which an editor strikes through and which goes at the next major version. Nothing has to change today. The request parameter type of that name is untouched.

• Four orderBy parameters list the fields they sort by. getPrecomputations, getPrecomputationsByID, getTrashedFieldsPaginated and searchWorkflows were typed string while their own documentation named the fields — functionKey, used, created, updated for the precomputations, and so on. Fifteen other orderBy parameters carry the list in the specification and were generated from it all along; these four carried it only in prose. They are now typed the same way, sort prefixes included:

  await jira.jqlFunctionsApps.getPrecomputationsByID({ precomputationIDs: [...], orderBy: '-created' });

  As everywhere else, the type stays open — 'created' | '-created' | '+created' | ... | (string & {}) — so an editor suggests the documented fields and any other string still compiles.

• Five more agile models are deprecated in favour of the components they were copies of. createBoard and getBoard answer with Board, getAllBoards with PageBoard, getBoardByFilterId with PageBoardFilter, and getAllQuickFilters with PageQuickFilter. Each of those responses is declared inline in the specification, field for field the component sitting beside it, so the generator had nothing to name it after but the operation — and the component it duplicated went unused: no agile model referenced Board at all, while six of them wrote a board out in full. The retired names are still exported as @deprecated aliases of the new ones, assignable in both directions, and go at the next major version. Nothing has to change today.

  A board reports its type properly now, as a side effect worth naming. Board.type is 'scrum' | 'kanban' | 'simple' | (string & {}); every copy of it was a plain string, and since each of these methods returned a copy, the narrowing reached none of them. getBoard() and the boards inside getAllBoards().values carry it now.

... (truncated)

Commits

• 87855cb fix: the assets suite stops claiming the two workspace paths still agree
• ef1506e feat: createCustomField lists the field types it accepts
• 29e102d feat: eleven cloud models lose the name of the serializer that made them
• fb3fc97 feat: a page's own fields are no longer optional
• fbf0899 feat: a page of things is typed Page<T>
• c317d88 fix: the board endpoints answer with Board, not with a copy named after the o...
• a5438f6 fix: the four orderBy parameters list the fields they sort by
• 340e2f7 refactor: a parameter type built on a model is written as one call
• 2bed09e refactor: GetQuickFilter stays, deprecated, rather than disappearing
• 6320699 refactor: the shared shapes keep the sentences that described the properties
• Additional commits viewable in compare view

[github-actions]

Automated review from approve-and-automerge-dependabot-prs workflow in exivity/actions

[github-actions]

Automated review from approve-and-automerge-dependabot-prs workflow in exivity/actions

[github-actions]

Automated review from approve-and-automerge-dependabot-prs workflow in exivity/actions

[github-actions]

Automated review from approve-and-automerge-dependabot-prs workflow in exivity/actions

[github-actions]

Automated review from approve-and-automerge-dependabot-prs workflow in exivity/actions