Improvement Suggestion: Refactoring and Consistency in Export Statements
- Dominant language
- TypeScript
- Stars
- 371
- Forks
- 248
- PR merge metrics
- No merged PRs in 30d
Description
## Issue Summary
The current export statements in the module could benefit from several improvements for consistency, readability, and maintainability. While the exports are functional, a few refinements can be made to follow best practices and align the code more closely with modern TypeScript conventions. This will ensure the codebase is clean, consistent, and scalable.
### Proposed Changes:
1. **Group Export Statements by Category:**
- Exports can be grouped into logical categories for better organization (e.g., actions, types, utils, decorators).
- This makes it easier for developers to locate relevant exports, and improves readability.
2. **Consolidate Similar Exports:**
- Instead of having multiple lines for similar types or functions, consider grouping them where possible. This reduces redundancy and makes the code more concise.
3. **Use `export { default as ... }` for Named Exports (where applicable):**
- If a module contains a default export and multiple named exports, we can use `export { default as ... }` syntax to clarify the distinction and keep it consistent.
4. **Ensure Correct Typing:**
- Double-check for any mismatched or redundant types in the exports, ensuring that types are appropriately and consistently applied.
### Example Refactor:
```ts
// Grouping export statements logically for clarity and readability
// Public actions
export { type ProvenWithdrawal } from './actions/public/L1/readProvenWithdrawals.js';
export { type ProveWithdrawalTransactionParameters } from './actions/wallet/L1/writeProveWithdrawalTransaction.js';
// Public L1 and L2 Op Stack Actions
export { type PublicL1OpStackActions, publicL1OpStackActions } from './decorators/publicL1OpStackActions.js';
export { type PublicL2OpStackActions, publicL2OpStackActions } from './decorators/publicL2OpStackActions.js';
// Wallet L1 and L2 Op Stack Actions
export { type WalletL1OpStackActions, walletL1OpStackActions } from './decorators/walletL1OpStackActions.js';
export { type WalletL2OpStackActions, walletL2OpStackActions } from './decorators/walletL2OpStackActions.js';
// Types related to addresses, deposits, and transactions
export type { Addresses, ContractAddress, RawOrContractAddress } from './types/addresses.js';
export type { DepositERC20Parameters, DepositETHParameters, DepositTransaction, TransactionDepositedEvent } from './types/depositTransaction.js';
export { DEPOSIT_TX_PREFIX, SourceHashDomain } from './types/depositTransaction.js';
export type { WithdrawETHParameters, WithdrawToParameters } from './types/withdrawTo.js';
// Gas Price Oracle and Transaction Parameters
export type { BlockOptions, GasPriceOracleEstimator, GasPriceOracleParameters, OracleTransactionParameters } from './types/gasPriceOracle.js';
// Contract-related types for Op Stack L2
export { type OpStackL2ChainContracts, opStackL2ChainContracts, OpStackL2Contract } from './types/opStackContracts.js';
// Events and utilities
export type { MessagePassedEvent } from './types/withdrawal.js';
export type { GetDepositTransactionParams } from './utils/getDepositTransaction.js';
export { getDepositTransaction, getL2HashFromL1DepositInfo, getSourceHash, getTransactionDepositedEvents, getWithdrawalMessageStorageSlot, rlpEncodeDepositTransaction } from './utils';
// Event types for transaction deposits
export type { GetTransactionDepositedEventsParams, GetTransactionDepositedEventsReturnType, TransactionDepositedEventDetails } from './utils/getTransactionDepositedEvents.js';
Contributor guide
Research direction
Start by locating the module that exports the listed actions, decorators, types, and utilities, then compare its current statements with the paths shown in the proposed refactor. Check the TypeScript build and existing tests after organizing and consolidating exports; done means the exports remain available with consistent typing and no redundant statements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- tooling
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100