chore: enable absolute import paths

[joaoloureirop]

Description

https://reactnative.dev/docs/typescript#using-custom-path-aliases-with-typescript

Allow absolute import paths relative to project root dir.

Related issues

Fixes:

Manual testing steps

1. Go to this page...

Screenshots/Recordings

Can be refactored into

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[Prithpal-Sooriya]

@joaoloureirop do we have linting on import orders? How does absolute imports fit in to the import order?

E.g. will the ordering be:

// Global imports
import { ... } from 'react-native'

// Absolute imports
import {...} from '~/foo'

// Relative imports
import {...} from '../bar'

[NicolasMassart]

Q: 2 questions:

• Is this ~ home syntax also available for mocking link in jest.mock('../../../../util/Logger'); to be jest.mock('~/util/Logger'); ?
• is there any risk for the ~ to be mixed up with the user home ~ in shell commands or scripts?

[joaoloureirop]

@joaoloureirop do we have linting on import orders? How does absolute imports fit in to the import order?

E.g. will the ordering be:

// Global imports
import { ... } from 'react-native'

// Absolute imports
import {...} from '~/foo'

// Relative imports
import {...} from '../bar'

I would order in terms of the relationship between components rather than by the import path format.

// 3rd party packages
import { ... } from 'react-native'

// shared components
import {...} from '~/foo'
import { ... } from '../../../CommonView'

// feature components
import { ... } from '../../FeatureTextInput'
import { ... } from '~/hooks/Feature/useFeature'

[joaoloureirop]

Q: 2 questions:

• Is this ~ home syntax also available for mocking link in jest.mock('../../../../util/Logger'); to be jest.mock('~/util/Logger'); ?

Good question. Jest might also need a config entry to resolve the aliases.

e.g.

"moduleNameMapper": {
  "~/app/(.*)": "<rootDir>/app/$1"
},

• is there any risk for the ~ to be mixed up with the user home ~ in shell commands or scripts?

These aliases are only applied on module paths that are resolved by the bundler through babel. It should not interfere with the shell

[joaoloureirop]

Need to investigate why these code changes interfere with jest and react-native-launch-arguments

Related issue:
iamolegga/react-native-launch-arguments#43

I'll consider mocking the function if no obvious solution is found

[OGPoyraz]

Personally, I feel this approach tends to introduce more complexity than it resolves in most cases. A few concerns that come to mind at first glance:

• It tightly couples the code to specific directory structures, which can make refactoring or moving code across the application more difficult.
• Requires additional build configurations across multiple tools (TypeScript, Metro, ESLint, Jest).
• Increases the maintenance overhead of the tooling setup.
• It can cause issues with IDE support.
• Complicates test setups and mocking, which can make maintaining tests more challenging.
• Migrating the existing codebase would require significant effort.

For context, a similar proposal was made in the extension project and ultimately not pursued:
MetaMask/metamask-extension#22857

That said, just my two cents.

[joaoloureirop]

• It tightly couples the code to specific directory structures, which can make refactoring or moving code across the application more difficult.

In fact, it is easier to refactor with import path aliases relative to the project root.

• easier to move files around (inner file imports relative to project root)
• easier to refactor import paths (think “Find & Replace”)
• easier to locate a file (mental model)

• Requires additional build configurations across multiple tools (TypeScript, Metro, ESLint, Jest).
• Increases the maintenance overhead of the tooling setup.
• It can cause issues with IDE support.
• Complicates test setups and mocking, which can make maintaining tests more challenging.

Agreed. The amount of extra setup required might outweigh the pros of custom path aliases.