Dependencies are imported efficiently

Barrel imports like import _ from 'lodash' or import AWS from 'aws-sdk' pull the entire library into the module graph at bundle time. Even with tree-shaking, not all packages are written to be tree-shakeable — lodash's default export is a single object, not named exports, so tree-shaking cannot eliminate the unused functions. The result is a client bundle that includes code paths you never call, increasing both payload size and the attack surface of your front-end JavaScript. The ISO 25010 performance-efficiency characteristic requires that resource use be proportional to functional demand; importing 71KB of utility functions to use three of them is a direct violation of that principle.

Switch to per-function or modular imports. For lodash:

// before — imports entire library
import _ from 'lodash'
// after — imports only what you use
import debounce from 'lodash/debounce'
import throttle from 'lodash/throttle'

For AWS SDK, migrate from the monolithic v2 to the modular v3:

// before
import AWS from 'aws-sdk'
const s3 = new AWS.S3()
// after
import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3'
const s3 = new S3Client({ region: 'us-east-1' })

For date-fns, named imports are already tree-shakeable — import { format } from 'date-fns' is fine as-is.

• ID: dependency-supply-chain.optimization.efficient-imports

• Severity: low

• What to look for: Search source code files (.ts, .tsx, .js, .jsx) for import patterns that pull in entire libraries when only a subset is needed. Specific patterns to flag:

  • import _ from 'lodash' or import * as _ from 'lodash' — whole lodash library
  • import * as icons from 'lucide-react' or import { Icon1, Icon2, ..., Icon20+ } from 'lucide-react' — large icon barrel imports
  • import * from 'date-fns' — whole date-fns library
  • import { everything } from '@mui/material' — large MUI barrel
  • import AWS from 'aws-sdk' (v2) — whole AWS SDK instead of modular v3 clients Note: if the framework supports tree-shaking (Next.js with Webpack/Turbopack, Vite), named imports from libraries that support it (e.g., import { format } from 'date-fns') are acceptable. Flag only cases where tree-shaking cannot help. Count all instances found and enumerate each.

• Pass criteria: No patterns found that import entire libraries when the framework's bundler cannot tree-shake them effectively. At least 1 implementation must be confirmed.

• Fail criteria: One or more import patterns are found that pull in an entire library when only a subset is used and tree-shaking is unlikely to eliminate the dead code.

• Skip (N/A) when: No source code files found, or package.json not detected.

• Detail on fail: "import _ from 'lodash' found in src/utils/helpers.ts — this imports the entire 24KB (gzipped) lodash library. Use lodash/function specific imports or native JS equivalents."

• Remediation: Inefficient imports bloat your JavaScript bundle, increasing page load times and hurting Core Web Vitals. For a comprehensive performance analysis, the Performance & Load Readiness Audit covers bundle analysis and load optimization in detail.

  // Lodash: use per-function imports
  import debounce from 'lodash/debounce'
  import throttle from 'lodash/throttle'
  
  // date-fns: named imports are fine (tree-shaking works)
  import { format, parseISO } from 'date-fns'
  
  // AWS SDK: use v3 modular clients
  // Instead of: import AWS from 'aws-sdk'
  import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3'