Ft/upgrade next to 15

[koechkevin]

Description

This PR upgrades the Next.js framework from the current version to v15.0.3 to leverage on the latest features, performance improvements, and bug fixes introduced in this release.

Key Changes

• Upgrade Next.js Version to 15.0.3.
• Upgrade Eslint to v9 since next js 15 added support for eslint 9.
• Updated codebase's eslint configuration to flatConfigs.
• Removed .eslintignore and .eslintrc since with flatConfigs all can be defined in eslint.config.js.

You may notice many changed files in component files, but this is due to a change in how to disable a rule in a file with flat configs.

• We do not need to replicate // eslint-disable-next-line testing-library/render-result-naming-convention inside the test file since this disable command has been specified in common eslint config "testing-library/render-result-naming-convention": "off",.
• // eslint-disable-next-line react-hooks/exhaustive-deps occurrences have now been replaced with /* eslint react-hooks/exhaustive-deps: "off" */

Review of this PR should be around */**/eslint.config.js and packages/eslint-config-commons-ui

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Screenshots

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation

[kilemensi]

👍🏽

---

Still going through it but quick feedback on issues that kind of stood out to me.

[kilemensi]

Why do we need this? Aren't we going all in Eslint 9?

[koechkevin]

@kilemensi I came across this issue and the only workaround I had was to use eslint compatibility utilities to fix up things.

[kilemensi]

👍🏽

---

Based on this comment, should we be using the experimental file configuration?

[koechkevin]

👍🏽

Based on this comment, should we be using the experimental file configuration?

@kilemensi this seems to work for js apps if we put eslint configs at root but since ts apps configurations have some differences, we may have to retain them as is.

[kilemensi]

@kilemensi this seems to work for js apps if we put eslint configs at root but since ts apps configurations have some differences, we may have to retain them as is.

There is a slight chance I've misread it @koechkevin so please read the docs again but my understanding is as follow:
Given the following directory tree:

  <root>
  ├── eslint.config.js
  ├── apps
  │   ├── centralcms
  │   ├── charterafrica
  │   │   ├── src
  │   │   ├── eslint.config.json
  │   ├── civicsignalblog
  ├── packages
  │   ├── commons-ui-core
  │   ├── commons-ui-next
  │   ├── commons-ui-payload

Without the flag, eslint looks for config from current directory moving up. That is, if you run the command at <root>, if there is a eslint.config.js at root, that config will be used regardless of any other config at apps level. If it doesn't find one at <root>, then it will travel <root> -> apps -> charterafrica and use the first found eslint.config.js along that path.

With the flag on, the process is actually reversed. eslint starts looking at the file being linted regardless of where the command was executed. So if we're linting a file in apps/charterafrica/src, eslint will traverse backwards and find eslint.config.json in charterafrica first, or along the path charterafrica -> apps -> <root> until it finds one.

In a monorepo, the second approach sounds like the right approach to me.

[kilemensi]

I just saw

chore: Remove obsolete ESLint configuration files across multiple app

fly by my screen @koechkevin. Are we changing the approach?

[koechkevin]

I just saw

chore: Remove obsolete ESLint configuration files across multiple app

fly by my screen @koechkevin. Are we changing the approach?

@kilemensi been playing around with this and it looks like even without a flag 🤔 eslint traverses backwards. So I just removed eslint configurations in apps and retained one in the root. I had to push it just to be sure that things aren't cached on my end.

[koechkevin]

@kelvinkipruto @m453h spare some time here

[kelvinkipruto]

@koechkevin Just tested it on ClimateMapped, and it works fantastic. Perhaps we can now use use cache to improve its speed😅.
Let me still review the other apps

[m453h]

🚀

I have tested CivicSignalBlog, ClimateMapped and VPNManager and they have worked , I'll need to test the remaining apps as well.

---

Just a thought I had as I was reading through this discussion... would it make sense to have a root-level eslint.config.js and extend it per specific app's needs ? Or would that lead to unnecessary complexity?

[koechkevin]

🚀

I have tested CivicSignalBlog, ClimateMapped and VPNManager and they have worked , I'll need to test the remaining apps as well.

Just a thought I had as I was reading through this discussion... would it make sense to have a root-level eslint.config.js and extend it per specific app's needs ? Or would that lead to unnecessary complexity?

@m453h The configs for all apps are similar, would it make sense to have as many eslint configs when only 1 at the root can work?

[m453h]

🚀
I have tested CivicSignalBlog, ClimateMapped and VPNManager and they have worked , I'll need to test the remaining apps as well.
Just a thought I had as I was reading through this discussion... would it make sense to have a root-level eslint.config.js and extend it per specific app's needs ? Or would that lead to unnecessary complexity?

@m453h The configs for all apps are similar, would it make sense to have as many eslint configs when only 1 at the root can work?

Yes, I was thinking that just one eslint.config.js file at the root level would make more sense, though I had seen we still had separate files for some apps like civicsignalblog, vpnmanager, techlab, uibook, pesayetu, promisetracker

[koechkevin]

🚀
I have tested CivicSignalBlog, ClimateMapped and VPNManager and they have worked , I'll need to test the remaining apps as well.
Just a thought I had as I was reading through this discussion... would it make sense to have a root-level eslint.config.js and extend it per specific app's needs ? Or would that lead to unnecessary complexity?

@m453h The configs for all apps are similar, would it make sense to have as many eslint configs when only 1 at the root can work?

Yes, I was thinking that just one eslint.config.js file at the root level would make more sense, though I had seen we still had separate files for some apps like civicsignalblog, vpnmanager, techlab, uibook, pesayetu, promisetracker

@m453h typescript apps' configurations are slightly different from those for JS apps so we'd have to retain app-level configurations for the TS apps.