chore: upgrade workflows and update dependencies

[borisonekenobi]

This pull request updates the project to support TypeScript 7 and modernizes the GitHub Actions workflows. It also improves type safety in the codebase and updates a test mock for better maintainability.

Dependency and TypeScript updates:

• Upgraded typescript to version 7.0.2 in package.json, package-lock.json, and added support for platform-specific TypeScript packages. The minimum Node.js version is now 16.20.0. (src/package.json, src/package-lock.json, [1] [2] [3] [4]
• Updated tsconfig.json to use module: node16 and moduleResolution: node16, aligning with TypeScript 7 requirements. (src/tsconfig.json, src/tsconfig.jsonL3-R4)

CI/CD workflow modernization:

• Updated all GitHub Actions in workflow YAML files to their latest major versions (e.g., actions/checkout@v7, actions/setup-node@v7, actions/upload-artifact@v7, actions/download-artifact@v8). (.github/workflows/main.yml, .github/workflows/npm-publish.yml, [1] [2] [3] [4] [5]

Type safety improvements:

• Improved the type of the beforeAdd hook in PublishOptions to use the GhPagesGit type instead of unknown, and imported the type accordingly. (src/interfaces.ts, [1] [2]
• Added a type assertion for options.project in ngAdd to satisfy stricter type checking. (src/ng-add.ts, src/ng-add.tsL23-R23)

Testing improvements:

• Refactored the mock for gh-pages/lib/git in the test file to use a class-based mock, improving clarity and maintainability. (src/engine/engine.gh-pages-integration.spec.ts, src/engine/engine.gh-pages-integration.spec.tsL25-R35)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[fmalcher]

Since this project is Europe-based, we should set this to Europe/Berlin

[fmalcher]

Same below

[borisonekenobi]

Fixed

[fmalcher]

What is the reason to set this to "node16" specifically?

[borisonekenobi]

Typescript v6 removes node as an available moduleResolution, and the suggested fix by GitHub Copilot was node16, other than that, no opinion on specific module or moduleResolution

[fmalcher]

We release this tool in a much larger interval, so I suggest monthly dep updates. Everything shorter than this is highly annoying for maintainers.

[borisonekenobi]

Fixed

[Copilot]

Copilot review overview

🔵 Needs a closer look

Resolve the Angular 18 compatibility and Node engine requirement inconsistencies in src/package.json.

Review effort: Lite
Findings: None

[fmalcher]

Thanks for the PR, @borisonekenobi 😊
Apart from my smaller comments, LGTM at first quick sight.
I have set up Dependabot in another project too, and like it 👍

[JohannesHoppe]

Hi @borisonekenobi, thank you so much for this PR and for taking the time to work through the review feedback! 🙏

The code changes are great: the class-based MockGit and the proper GhPagesGit type for beforeAdd are real improvements, and I'd love to merge them. The TypeScript upgrade and the upgraded GitHub Actions are fine with me too.

Dependabot is where I have a real stomachache, though. Supply-chain attacks have become a huge problem in the npm ecosystem, and according to GitHub, 66,408 repositories depend on angular-cli-ghpages. Every dependency change I ship ends up in all of those build pipelines, and I take that responsibility seriously. That's why I've deliberately cut down the dependency footprint over time. I even inlined and slimmed down former dependencies so there's less code from third parties in the chain.

My approach: outdated dependencies on their own aren't a problem. If there's a security finding, it gets handled right away. Otherwise I update dependencies by hand before each release, alongside Angular/AngularFire, and test everything together. A bot that continuously bumps versions works against that. The devDependencies are also intentionally pinned to the lowest supported Angular version (18), so the build always runs against the minimum the package claims to support (see docs/README_contributors.md).

So would you mind trimming the PR down to the code changes? Concretely:

• remove .github/dependabot.yml
• drop the remaining Dependabot bump commits for the other devDependencies (keep the TypeScript bump in package.json and the GitHub Actions upgrades in the workflow files)
• drop the changes to package-lock.json, I'll regenerate it myself

That leaves the MockGit refactoring, the beforeAdd type, the TypeScript upgrade (including the tsconfig.json change and the as string cast in ng-add.ts) and the GitHub Actions upgrades, which I'm happy to merge. I'll do the next round of dependency updates (Vitest etc.) myself before the next release.

Thanks again, contributions like this are really appreciated! 😊

[JohannesHoppe]

see comment

[borisonekenobi]

Thanks for the detailed feedback. I understand the concern, especially given how many downstream projects use the package and the responsibility that comes with changing its dependency chain.

I can trim the PR as requested, but I wanted to point out a few details first. Not all of the dependency updates in this PR are just version bumps. Some of them resolve security vulnerabilities that Dependabot found. The updates reduce the reported vulnerabilities from 83 to 1. (link to resolved vulnerabilities) The remaining vulnerability hasn't been resolved in the upstream packages yet, so there is currently no update that can address it (and, unfortunately, that vulnerability is also what originally prompted me to start this PR).

With that in mind, I wanted to suggest a slightly different approach:

1. Keep the dependency updates that actually resolve the reported vulnerabilities. These differ from routine dependency updates because they directly address known security issues.

2. Configure Dependabot to only create PRs for security updates. This would let you handle security findings immediately while continuing to update other dependencies manually before releases. It would also avoid the continuous stream of routine version bumps that you are concerned about.

3. If you are open to it, keep the Dependabot configuration for the GitHub Actions. These updates do not affect the dependency tree of downstream repositories, and they are generally more isolated from the package itself. They also rarely introduce breaking changes to the workflow.

If you would still prefer to remove Dependabot completely, that is fine too. I want to flag this before we remove everything, as we may be able to keep the security benefits without continuous dependency updates.

Either way, I can make the changes and get the PR into a state you are comfortable merging.

[JohannesHoppe]

Thanks for the thoughtful reply and for raising the security side before trimming!

1. Vulnerabilities: Most findings come from package-lock.json. That file isn't part of the published package, though. When someone installs angular-cli-ghpages, they only get our version ranges from dependencies (@angular-devkit/*, which resolve to the project's own Angular version, and gh-pages), resolved against their own lockfile. So the actual impact on users is very limited. The only finding that really reaches them is braces (via gh-pages → globby → fast-glob → micromatch). braces itself has no patched version yet, so even the latest releases of that chain still pull it in. Since the glob patterns come from our own config, I see little practical risk there. Getting rid of gh-pages altogether is already on my TODO list anyway, since it's the last big avoidable dependency.

But security isn't only about users: the maintainers' machines and the CI run with that lockfile too, so the findings do matter. That's why I'll regenerate the lockfile myself before merging, which resolves them.

2. Security-only updates: Good idea, and it fits my approach. I'll enable Dependabot alerts in the repo settings instead, so I get notified without automated PRs.

3. GitHub Actions: I see it differently: the actions run in our npm publish pipeline, so a compromised action could ship a malicious release to every downstream project. I'd rather not bump those automatically. The one-time upgrade in this PR is great, though!

So please remove .github/dependabot.yml, the remaining devDependency bumps and the lockfile changes, and keep the code changes, the TypeScript upgrade and the Actions upgrades. Then I'm happy to merge.

Thanks again, and I'm sorry for the extra work! I'm honestly concerned about the state of the npm ecosystem and the overall security landscape, especially now that AI is finding every little attack vector.

[borisonekenobi]

No worries, and thanks for clarifying! I understand your reasoning around the lockfile and the GitHub Actions.

I've made the changes, and the PR is ready for review again!