Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ft/upgrade next to 15 #1001

Merged
merged 35 commits into from
Jan 15, 2025
Merged

Ft/upgrade next to 15 #1001

merged 35 commits into from
Jan 15, 2025

Conversation

koechkevin
Copy link
Contributor

@koechkevin koechkevin commented Nov 14, 2024

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",.

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

Find a write-up of how these configs work here

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

@koechkevin koechkevin marked this pull request as draft November 14, 2024 10:51
@koechkevin koechkevin self-assigned this Nov 14, 2024
@koechkevin koechkevin requested a review from a team November 27, 2024 10:56
@koechkevin koechkevin marked this pull request as ready for review November 27, 2024 10:56
Copy link
Member

@kilemensi kilemensi left a comment

Choose a reason for hiding this comment

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

👍🏽


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

packages/eslint-config-commons-ui/next.js Show resolved Hide resolved
packages/hurumap-next/eslint.config.js Outdated Show resolved Hide resolved
apps/vpnmanager/src/middleware.ts Outdated Show resolved Hide resolved
@koechkevin koechkevin requested a review from kilemensi December 2, 2024 12:46
Copy link
Member

@kilemensi kilemensi left a comment

Choose a reason for hiding this comment

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

👍🏽


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

apps/charterafrica/src/components/Articles/Articles.js Outdated Show resolved Hide resolved
apps/vpnmanager/package.json Outdated Show resolved Hide resolved
apps/vpnmanager/src/lib/outline.ts Outdated Show resolved Hide resolved
@koechkevin
Copy link
Contributor Author

👍🏽

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
Copy link
Member

kilemensi commented Dec 4, 2024

@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
Copy link
Member

I just saw

chore: Remove obsolete ESLint configuration files across multiple app

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

@koechkevin
Copy link
Contributor Author

@CodeForAfrica/tech ?

@m453h
Copy link
Contributor

m453h commented Jan 9, 2025

@CodeForAfrica/tech ?

Hi @koechkevin just early feedback tested running several apps noticed there is an issue on CivicSignal Research, its failing to resolve this custom component

src/payload/components/allowedAppSelect/index.js

I did a quick test by renaming the component to .tsx and importing it as shown below 👇 and it resolves this issue.

import CustomSelectComponent from "#civicsignalblog/payload/components/allowedAppSelect/index"

I recall keeping this component with .js extension in order to auto import this component without needing to use the index name e.g. in defaultApp.js, and currentApp.js haven't figured out yet why moving to the eslint.config.js is causing this issue though

@kelvinkipruto
Copy link
Contributor

@koechkevin A few issues I have encountered.

  1. In NextJs 15, Dynamic APIs are Asynchronous. Some props must be awaited. techlabblog throws errors regarding this. Running the recommended codemod fixes it.
  2. "target": "ES2017" is missing in climatemappedfrica's tsconfig.json
  3. Looking at the eslint.config.js for the typescript apps, they are all similar. Is it possible to have one configuration that can be reused for all the apps?

@koechkevin
Copy link
Contributor Author

import CustomSelectComponent

Renamed to index.tsx and I don't seem to find any issue @m453h

@m453h
Copy link
Contributor

m453h commented Jan 10, 2025

import CustomSelectComponent

Renamed to index.tsx and I don't seem to find any issue @m453h

Great we can keep the custom components in tsx, have you changed the import ? Because build would fail to resolve the module unless we explicitly import it as:

import CustomSelectComponent from "#civicsignalblog/payload/components/allowedAppSelect/index";

@kilemensi
Copy link
Member

kilemensi commented Jan 13, 2025

@koechkevin , to move things along, this is what I raised on Friday:

Before this upgrade, there were 2 eslint configs in eslint-config-commons-ui:

  1. index.js: This is the default config and it's the React only config (JavaScript only). It is useful in other packages e.g. commons-ui/core, hurumap/core, etc., that do not use Next.js
  2. next.js: This is the Next.js config (JavaScript only). It is useful in both packages and apps that use Next.js.

Each package/app chose which of the above config to use and import it via package/app-level .eslintrc.js

Moving to eslint 9, my questions are:

  1. How are we introducing TypeScript support (initially just Next.js)?
  2. Based on 1, how many "reusable" configs will we now have in the eslint-config-commons-ui?
  3. Using flatConfig, where and how are the various eslint.config.js applied to cover all packages and apps in the repo?

@koechkevin
Copy link
Contributor Author

koechkevin commented Jan 13, 2025

@koechkevin , to move things along, this is what I raised on Friday:

Before this upgrade, there were 2 eslint configs in eslint-config-commons-ui:

  1. index.js: This is the default config and it's the React only config (JavaScript only). It is useful in other packages e.g. commons-ui/core, hurumap/core, etc., that do not use Next.js
  2. next.js: This is the Next.js config (JavaScript only). It is useful in both packages and apps that use Next.js.

Each package/app chose which of the above config to use and import it via package/app-level .eslintrc.js

Moving to eslint 9, my questions are:

  1. How are we introducing TypeScript support (initially just Next.js)?
  2. Based on 1, how many "reusable" configs will we now have in the eslint-config-commons-ui?
  3. Using flatConfig, where and how are the various eslint.config.js applied to cover all packages and apps in the repo?

@kilemensi to answer your questions,
Since we are now using eslint --flag unstable_config_lookup_from_file --fix './' command, we have 1 eslint.config.js that will be used by all next js apps which do not have their own eslint.config.js.

  1. We are introducing common configs for typescript-next apps i.e typescript.js in eslint-common-config. This basically extends ./next configs and adds extra configs for typescript apps. Individual apps will now have their own eslint.config.js implementing these configs.
const eslintConfig = require("eslint-config-commons-ui/typescript");

module.exports = eslintConfig;
  1. We now have 3 reusable configs i.e index.js, next.js and typescript.js
  2. For the packages, we only have one config file under packages directory which implements index.js

@kilemensi
Copy link
Member

  1. For the packages, we only have one config file under packages directory which implements index.js

Some packages such as commons-ui/next, hurumap-next, etc. should be checked with next.js instead of index.js @koechkevin.

@koechkevin
Copy link
Contributor Author

  1. For the packages, we only have one config file under packages directory which implements index.js

Some packages such as commons-ui/next, hurumap-next, etc. should be checked with next.js instead of index.js @koechkevin.

@kilemensi
For the packages that use the next configs, we use the same approach as we used in typescript-next. They have their own config files extending ./next. commons-ui-next extended index.js was it a mistake?

@kilemensi
Copy link
Member

... commons-ui-next extended index.js was it a mistake?

Most likely @koechkevin; see hurumap-next

@kilemensi kilemensi requested a review from a team January 13, 2025 13:48
@kilemensi kilemensi added the chore A task that needs to be done (neither enhancement or bug) label Jan 13, 2025
@koechkevin
Copy link
Contributor Author

closes #1023 #1024

@koechkevin
Copy link
Contributor Author

@m453h @kelvinkipruto ?

Copy link
Contributor

@kelvinkipruto kelvinkipruto left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@m453h m453h left a comment

Choose a reason for hiding this comment

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

Looks good to me, nothing major but I've just noticed the warning (when I run the lint command) 👇

Warning: React version was set to "detect" in eslint-plugin-react settings, but the "react" package is not installed. Assuming latest React version for linting.

Shouldn't we explicitly set the react version ? 🤔

…t settings, but the "react" package is not installed.
@kilemensi
Copy link
Member

I take @CodeForAfrica/tech are happy with this PR @koechkevin ? If yes, lets merge it. Any outstanding issue, will be fix in a separate PR.

@koechkevin koechkevin added this pull request to the merge queue Jan 15, 2025
Merged via the queue into main with commit 6cce436 Jan 15, 2025
5 of 6 checks passed
@koechkevin koechkevin deleted the ft/upgrade_next_to_15 branch January 15, 2025 11:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore A task that needs to be done (neither enhancement or bug)
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

4 participants