docs: update import example for v10 named export

[yzxcj797]

Fixes #606. v10 changed the export from default to named. Updated the programmatic API example to use const { concurrently } = require("concurrently").

[gustavohenke]

Preferring #611 over this.

[Bibin-VR]

Thanks for picking this up — the named export is the right call.

Two things the example may still trip on, both because v10 is pure ESM ("type": "module", and exports maps only ./dist/lib/index.js):

1. __dirname two lines below

cwd: path.resolve(__dirname, 'scripts/watchers'),

__dirname doesn't exist in an ES module, so a reader copying this into an .mjs file or a "type": "module" project gets ReferenceError: __dirname is not defined. import.meta.dirname is the equivalent, and engines already requires Node >=22, so it's safe to use unconditionally.

2. require() on a pure-ESM package

const { concurrently } = require('concurrently') does work on Node ≥22.12 via require(esm), so this PR is a genuine improvement. But documenting CJS for an ESM-only package is a bit of a mixed signal, and it's why the destructure is needed in the first place — require() hands back the module namespace rather than the function.

Verified against published concurrently@10.0.5 on Node 22:

pattern	result
const concurrently = require('concurrently')	typeof → object, call throws
const { concurrently } = require('concurrently')	works
import { concurrently } from 'concurrently'	works

If it's useful, the fully-ESM version:

import path from 'node:path';
import { concurrently } from 'concurrently';

const { result } = concurrently(
  [
    'npm:watch-*',
    { command: 'nodemon', name: 'server' },
    { command: 'deploy', name: 'deploy', env: { PUBLIC_KEY: '...' } },
    {
      command: 'watch',
      name: 'watch',
      cwd: path.resolve(import.meta.dirname, 'scripts/watchers'),
    },
  ],
  {
    prefix: 'name',
    killOthersOn: ['failure', 'success'],
    restartTries: 3,
    cwd: path.resolve(import.meta.dirname, 'scripts'),
  },
);
result.then(success, failure);

Happy either way — entirely your call whether the __dirname part belongs in this PR or a follow-up.