Skip to content

🩹 β€” Avoid duplicate key "types" in tsconfig#7610

Merged
JohnMcLear merged 1 commit intoether:developfrom
framasoft:fix-tsconfig
Apr 28, 2026
Merged

🩹 β€” Avoid duplicate key "types" in tsconfig#7610
JohnMcLear merged 1 commit intoether:developfrom
framasoft:fix-tsconfig

Conversation

@ldidry
Copy link
Copy Markdown
Contributor

@ldidry ldidry commented Apr 27, 2026

The key types is present two times in src/tsconfig.json, issuing warnings in log:

[2026-04-27T12:32:09.976] [INFO] Minify - Compress CSS file skins/colibris/index.css.
β–² [WARNING] Duplicate key "types" in object literal [duplicate-object-key]
    tsconfig.json:18:4:
      18 β”‚     "types": ["node", "jquery", "mocha"]
         β•΅     ~~~~~~~
  The original key "types" is here:
    tsconfig.json:6:4:
      6 β”‚     "types": ["node", "jquery"],
        β•΅     ~~~~~~~

This PR remove the first types, which contains only two values.

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

Review Summary by Qodo

Remove duplicate "types" key from tsconfig.json

🐞 Bug fix

Grey Divider

Walkthroughs

Description
β€’ Remove duplicate "types" key from tsconfig.json
β€’ Consolidate TypeScript type definitions into single entry
β€’ Eliminate compiler warnings about duplicate object keys
Diagram
flowchart LR
  A["tsconfig.json<br/>with duplicate types"] -- "remove first types entry" --> B["tsconfig.json<br/>single types definition"]
Loading

Grey Divider

File Changes

1. src/tsconfig.json 🐞 Bug fix +0/-1

Remove duplicate types key from config

β€’ Removed duplicate "types" key from compilerOptions
β€’ Kept the second "types" entry with extended type definitions
β€’ Eliminated TypeScript compiler warnings about duplicate keys

src/tsconfig.json


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

qodo-free-for-open-source-projects Bot commented Apr 27, 2026

Code Review by Qodo

🐞 Bugs (0) πŸ“˜ Rule violations (1)

Grey Divider


Action required

1. No test for tsconfig fix πŸ“˜ Rule violation ☼ Reliability
Description
This PR fixes a warning-causing bug (duplicate types key) but does not add an automated regression
test/check that would fail if the duplicate key were reintroduced. Without a test, the issue can
silently regress in future changes.
Code

src/tsconfig.json[6]

-    "types": ["node", "jquery"],
Evidence
PR Compliance ID 1 requires a regression test for bug fixes. The diff shows only a configuration
change removing the duplicated types key and includes no accompanying test/check changes in this
PR diff.

src/tsconfig.json[6-6]
Best Practice: Repository guidelines

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A bug fix was made to `src/tsconfig.json` (removing a duplicate `types` key), but there is no automated regression test/check to prevent reintroducing duplicate keys.

## Issue Context
Build tooling already emitted a warning about the duplicate key. A lightweight CI check (test or lint-like script) should fail if `src/tsconfig.json` contains duplicate keys (especially `types`) so the fix is verifiable and non-regressing.

## Fix Focus Areas
- src/tsconfig.json[6-6]

β“˜ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

Comment thread src/tsconfig.json
/* Visit https://aka.ms/tsconfig to read more about this file */
"moduleDetection": "force",
"lib": ["ES2023", "DOM"],
"types": ["node", "jquery"],
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. No test for tsconfig fix πŸ“˜ Rule violation ☼ Reliability

This PR fixes a warning-causing bug (duplicate types key) but does not add an automated regression
test/check that would fail if the duplicate key were reintroduced. Without a test, the issue can
silently regress in future changes.
Agent Prompt
## Issue description
A bug fix was made to `src/tsconfig.json` (removing a duplicate `types` key), but there is no automated regression test/check to prevent reintroducing duplicate keys.

## Issue Context
Build tooling already emitted a warning about the duplicate key. A lightweight CI check (test or lint-like script) should fail if `src/tsconfig.json` contains duplicate keys (especially `types`) so the fix is verifiable and non-regressing.

## Fix Focus Areas
- src/tsconfig.json[6-6]

β“˜ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@JohnMcLear
Copy link
Copy Markdown
Member

@ldidry how did this manifest? Did you get a warning/error? Thanks for the PR :) Hope you are doing good buddy!

@JohnMcLear JohnMcLear merged commit b16e4ff into ether:develop Apr 28, 2026
16 checks passed
@ldidry
Copy link
Copy Markdown
Contributor Author

ldidry commented Apr 28, 2026

I got the above warning in the logs, which I read when testing a new release to be sure that all plugins works well.

I’m doing fine, thank you. Hope you’re doing well too πŸ™‚

@ldidry ldidry deleted the fix-tsconfig branch April 28, 2026 07:14
JohnMcLear added a commit to JohnMcLear/etherpad that referenced this pull request Apr 28, 2026
 ether#7610)

Adds an `apt-publish` workflow job that turns the existing `.deb`
build artefacts into a signed apt repository hosted at:

  https://etherpad.org/apt/

End-user install on any Debian/Ubuntu/Mint:

  curl -fsSL https://etherpad.org/key.asc \
    | sudo gpg --dearmor -o /usr/share/keyrings/etherpad.gpg
  echo "deb [signed-by=/usr/share/keyrings/etherpad.gpg] \
       https://etherpad.org/apt stable main" \
    | sudo tee /etc/apt/sources.list.d/etherpad.list
  sudo apt update && sudo apt install etherpad

`apt upgrade` works going forward β€” every tagged release republishes
the repo metadata.

Change type: patch (CI/distribution; no production behaviour change).

## Why etherpad.org/apt and not ether.github.io/etherpad/apt

ether/etherpad's GitHub Pages is already configured as
build-from-workflow on `develop` with CNAME `docs.etherpad.org`, and
a repo can only have one Pages source. Pushing the apt repo to a
gh-pages branch would either be ignored (Pages is reading from the
docs workflow) or, if Pages were switched to it, would kill the docs
site. ether/ether.github.com is a separate Next.js site that already
deploys etherpad.org and serves `public/` verbatim, so cross-pushing
the apt repo into `public/apt/` lands it at the canonical Etherpad
URL with no infrastructure conflicts.

## What this PR ships

1. `apt-publish` job in `.github/workflows/deb-package.yml`. Runs after
   `release` on `v*` tag pushes:
     - Clones ether/ether.github.com over SSH using a deploy key.
     - Wipes site/public/apt/ and rebuilds it from the per-arch .deb
       artefacts using apt-ftparchive.
     - Signs Release + emits InRelease/Release.gpg using the keypair
       in APT_SIGNING_KEY.
     - Drops key.asc into site/public/key.asc.
     - Asserts both per-arch .debs are present before the wipe takes
       effect β€” refuses to publish a partial / empty repo if an
       artefact is missing or renamed.
     - Commits and pushes to master; the site repo's existing build
       pipeline picks it up.
2. `packaging/apt/key.asc` β€” Etherpad APT Repository public key,
   fingerprint 6953FA0C6431F30347D65B03AF0CD687D51A6E63. Served at
   https://etherpad.org/key.asc after the next release.
3. `packaging/apt/generate-signing-key.sh` β€” one-shot helper that
   generated the keypair, kept for documented future rotation.
4. `packaging/README.md` β€” apt-repo install recipe is now the
   recommended path.

## Required secrets before the next tagged release

Two secrets on ether/etherpad before the next `v*` tag push:

- APT_SIGNING_KEY β€” ASCII-armoured private key for the Etherpad APT
  Repository keypair (long key id AF0CD687D51A6E63), generated with
  packaging/apt/generate-signing-key.sh.
- SITE_DEPLOY_KEY β€” SSH private key. The public half registered as a
  deploy key with WRITE access on ether/ether.github.com.

If either is missing the job fails fast with a clear error.

## What this PR does not change

- The release job still attaches both versioned (etherpad_<v>_<arch>.deb)
  and stable-aliased (etherpad-latest_<arch>.deb) artefacts to the
  GitHub Release. Anyone pulling from
  releases/latest/download/etherpad-latest_amd64.deb keeps working.
- The build-job smoke test (start under systemd, /health, purge) is
  unchanged.
- docs.etherpad.org is untouched; this PR never pushes to gh-pages.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
JohnMcLear added a commit to JohnMcLear/etherpad that referenced this pull request Apr 28, 2026
 ether#7610)

Adds an `apt-publish` workflow job that turns the existing `.deb`
build artefacts into a signed apt repository hosted at:

  https://etherpad.org/apt/

End-user install on any Debian/Ubuntu/Mint:

  curl -fsSL https://etherpad.org/key.asc \
    | sudo gpg --dearmor -o /usr/share/keyrings/etherpad.gpg
  echo "deb [signed-by=/usr/share/keyrings/etherpad.gpg] \
       https://etherpad.org/apt stable main" \
    | sudo tee /etc/apt/sources.list.d/etherpad.list
  sudo apt update && sudo apt install etherpad

`apt upgrade` works going forward β€” every tagged release republishes
the repo metadata.

Change type: patch (CI/distribution; no production behaviour change).

## Why etherpad.org/apt and not ether.github.io/etherpad/apt

ether/etherpad's GitHub Pages is already configured as
build-from-workflow on `develop` with CNAME `docs.etherpad.org`, and
a repo can only have one Pages source. Pushing the apt repo to a
gh-pages branch would either be ignored (Pages is reading from the
docs workflow) or, if Pages were switched to it, would kill the docs
site. ether/ether.github.com is a separate Next.js site that already
deploys etherpad.org and serves `public/` verbatim, so cross-pushing
the apt repo into `public/apt/` lands it at the canonical Etherpad
URL with no infrastructure conflicts.

## What this PR ships

1. `apt-publish` job in `.github/workflows/deb-package.yml`. Runs after
   `release` on `v*` tag pushes:
     - Clones ether/ether.github.com over SSH using a deploy key.
     - Wipes site/public/apt/ and rebuilds it from the per-arch .deb
       artefacts using apt-ftparchive.
     - Signs Release + emits InRelease/Release.gpg using the keypair
       in APT_SIGNING_KEY.
     - Drops key.asc into site/public/key.asc.
     - Asserts both per-arch .debs are present before the wipe takes
       effect β€” refuses to publish a partial / empty repo if an
       artefact is missing or renamed.
     - Commits and pushes to master; the site repo's existing build
       pipeline picks it up.
2. `packaging/apt/key.asc` β€” Etherpad APT Repository public key,
   fingerprint 6953FA0C6431F30347D65B03AF0CD687D51A6E63. Served at
   https://etherpad.org/key.asc after the next release.
3. `packaging/apt/generate-signing-key.sh` β€” one-shot helper that
   generated the keypair, kept for documented future rotation.
4. `packaging/README.md` β€” apt-repo install recipe is now the
   recommended path.

## Required secrets before the next tagged release

Two secrets on ether/etherpad before the next `v*` tag push:

- APT_SIGNING_KEY β€” ASCII-armoured private key for the Etherpad APT
  Repository keypair (long key id AF0CD687D51A6E63), generated with
  packaging/apt/generate-signing-key.sh.
- SITE_DEPLOY_KEY β€” SSH private key. The public half registered as a
  deploy key with WRITE access on ether/ether.github.com.

If either is missing the job fails fast with a clear error.

## What this PR does not change

- The release job still attaches both versioned (etherpad_<v>_<arch>.deb)
  and stable-aliased (etherpad-latest_<arch>.deb) artefacts to the
  GitHub Release. Anyone pulling from
  releases/latest/download/etherpad-latest_amd64.deb keeps working.
- The build-job smoke test (start under systemd, /health, purge) is
  unchanged.
- docs.etherpad.org is untouched; this PR never pushes to gh-pages.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
JohnMcLear added a commit that referenced this pull request Apr 28, 2026
 #7610) (#7624)

* ci(packaging): publish signed apt repository to etherpad.org/apt (closes #7610)

Adds an `apt-publish` workflow job that turns the existing `.deb`
build artefacts into a signed apt repository hosted at:

  https://etherpad.org/apt/

End-user install on any Debian/Ubuntu/Mint:

  curl -fsSL https://etherpad.org/key.asc \
    | sudo gpg --dearmor -o /usr/share/keyrings/etherpad.gpg
  echo "deb [signed-by=/usr/share/keyrings/etherpad.gpg] \
       https://etherpad.org/apt stable main" \
    | sudo tee /etc/apt/sources.list.d/etherpad.list
  sudo apt update && sudo apt install etherpad

`apt upgrade` works going forward β€” every tagged release republishes
the repo metadata.

Change type: patch (CI/distribution; no production behaviour change).

## Why etherpad.org/apt and not ether.github.io/etherpad/apt

ether/etherpad's GitHub Pages is already configured as
build-from-workflow on `develop` with CNAME `docs.etherpad.org`, and
a repo can only have one Pages source. Pushing the apt repo to a
gh-pages branch would either be ignored (Pages is reading from the
docs workflow) or, if Pages were switched to it, would kill the docs
site. ether/ether.github.com is a separate Next.js site that already
deploys etherpad.org and serves `public/` verbatim, so cross-pushing
the apt repo into `public/apt/` lands it at the canonical Etherpad
URL with no infrastructure conflicts.

## What this PR ships

1. `apt-publish` job in `.github/workflows/deb-package.yml`. Runs after
   `release` on `v*` tag pushes:
     - Clones ether/ether.github.com over SSH using a deploy key.
     - Wipes site/public/apt/ and rebuilds it from the per-arch .deb
       artefacts using apt-ftparchive.
     - Signs Release + emits InRelease/Release.gpg using the keypair
       in APT_SIGNING_KEY.
     - Drops key.asc into site/public/key.asc.
     - Asserts both per-arch .debs are present before the wipe takes
       effect β€” refuses to publish a partial / empty repo if an
       artefact is missing or renamed.
     - Commits and pushes to master; the site repo's existing build
       pipeline picks it up.
2. `packaging/apt/key.asc` β€” Etherpad APT Repository public key,
   fingerprint 6953FA0C6431F30347D65B03AF0CD687D51A6E63. Served at
   https://etherpad.org/key.asc after the next release.
3. `packaging/apt/generate-signing-key.sh` β€” one-shot helper that
   generated the keypair, kept for documented future rotation.
4. `packaging/README.md` β€” apt-repo install recipe is now the
   recommended path.

## Required secrets before the next tagged release

Two secrets on ether/etherpad before the next `v*` tag push:

- APT_SIGNING_KEY β€” ASCII-armoured private key for the Etherpad APT
  Repository keypair (long key id AF0CD687D51A6E63), generated with
  packaging/apt/generate-signing-key.sh.
- SITE_DEPLOY_KEY β€” SSH private key. The public half registered as a
  deploy key with WRITE access on ether/ether.github.com.

If either is missing the job fails fast with a clear error.

## What this PR does not change

- The release job still attaches both versioned (etherpad_<v>_<arch>.deb)
  and stable-aliased (etherpad-latest_<arch>.deb) artefacts to the
  GitHub Release. Anyone pulling from
  releases/latest/download/etherpad-latest_amd64.deb keeps working.
- The build-job smoke test (start under systemd, /health, purge) is
  unchanged.
- docs.etherpad.org is untouched; this PR never pushes to gh-pages.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* ci(packaging): emit unindented Release headers + tighten artefact glob

Two corrections from a fresh Qodo review of the rebased apt-publish
job:

1. The dists/${SUITE}/Release heredoc was indented with the workflow's
   YAML scope, which means the resulting file had 10-space-prefixed
   field lines (`          Origin: Etherpad`). apt parsers reject any
   leading whitespace on header fields per RFC 822 / Debian control
   format, so the entire suite would have failed to parse on `apt
   update` even before checksums were appended.

   Replace the heredoc with `printf '%s\n' ...` so the indentation is
   entirely under workflow control and impossible to break with a
   future YAML re-indent.

2. Tighten the artefact glob from `etherpad_*_amd64.deb` to
   `etherpad_[0-9]*_amd64.deb`. The hyphen-separator distinction
   (etherpad_<v>_… vs etherpad-latest_…) already kept the alias out
   of the array β€” Qodo's analysis of a duplicate-Packages bug was
   incorrect. But pinning to a leading-digit version segment makes
   the contract explicit and defends against any future alias that
   accidentally lands on `dist/etherpad_<word>_<arch>.deb`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants