maorleger opened a new pull request, #441:
URL: https://github.com/apache/arrow-js/pull/441

   This PR trims the list of runtime dependencies from 9 down to 4 
   (`@types/node`, `flatbuffers`, `json-with-bigint`, `tslib` stay).
   
   Two pieces here:
   
   ## @swc/helpers
   
   Moving to devDependencies. The published library and CLI are both
   compiled by TSC (`gulp-typescript` + `tsconfig.bin.cjs.json`), and
   `importHelpers: true` in our tsconfig means the emitted code imports
   from `tslib`, never `@swc/helpers` - `grep -r '@swc/helpers' targets/`
   on a freshly built tree returns zero matches in any `.js`/`.mjs`/`.d.ts`.
   
   The only path that touches SWC at all is the dev-time bin shebangs that
   go through `@swc-node/register/esm-register`, and that path keeps
   working with `@swc/helpers` in devDeps (verified by removing it from
   `dependencies`, blowing away node_modules + the lockfile, reinstalling,
   and running both the test suite and `bin/file-to-stream.ts` end-to-end).
   
   I considered deleting it entirely since `@swc-node/register` indirectly
   pulls it in, but keeping it as an explicit devDep felt safer in case
   upstream changes that. 
   
   Per the [SWC 
docs](https://swc.rs/docs/configuration/compilation#jscexternalhelpers),
   `externalHelpers` is a bundle-size knob - it doesn't enable any
   features - and most of the source needs zero helper emissions anyway
   because the targets are modern enough that `async`/`await`/`class extends`
   compile to themselves.
   
   ## command-line-args and command-line-usage
   
   The only piece of the published package that actually needs an argv
   parser is the `arrow2csv` CLI. `node:util.parseArgs` has been stable
   since Node 18.3, which is well below the min version specified here, 
   so we don't strictly need the two libraries (plus their
   transitive trees of `chalk`, `lodash`, `table-layout`, etc.) to be
   installed alongside `apache-arrow` for every consumer.
   
   This PR adds a small internal helper at `src/bin/cli.ts` that wraps
   `parseArgs` and provides a plain-text `formatUsage`. 
   
   ### Callout
   
   The one tricky bit was that `command-line-args` treats `multiple: true` 
greedily -
   `-s a b c` puts all three into `schema` - while `parseArgs` only
   honors the repeated-flag form. I wanted to keep `arrow2csv` behavior
   identical, so the helper opts in to `tokens: true` and reattributes
   positionals that follow a `multiple: true` flag back to that flag's
   array. The unit tests in `test/unit/bin/cli-tests.ts` lock in the
   greedy and non-greedy cases side-by-side. The dev-only `bin/integration.ts`,
   `bin/json-to-arrow.ts`, and `gulp/argv.js` get migrated over in the
   same pass.
   
   We could significantly simplify the cli.ts file if we can forgo that 
requirement,
   but I opted to keep full compat for now.
   
   A few small things that `command-line-args` and `command-line-usage`
   support that this helper doesn't (none currently used by anything in
   `arrow2csv`):
   - Custom `type: (val) => ...` coercion functions
   - `lazyMultiple`, `defaultOption`, `group`, `camelCase`,
     `stopAtFirstUnknown`
   - ANSI styling (`{bold ...}` / `{underline ...}` markers are stripped
     to plain text rather than colored)
   - Text wrapping of descriptions and `typeLabel` rendering in the help
     screen - the `typeLabel` field is accepted on the spec but not
     rendered. None of our help text is wide enough to need wrapping.
   
   Happy to add any of these back if reviewers prefer; my read is that
   the unused-feature surface isn't worth re-implementing.
   
   Validation:
   - `npm run lint:ci` clean
   - `npm test -- -t src` passes (46 suites, ~11.7k tests, plus the new
     cli-tests.ts)
   - `npm run build` succeeds for all 10 target/format combos
   - `npm run test:bundle` (esbuild + rollup + webpack) all run clean
   - End-to-end smoke tests of `node targets/apache-arrow/bin/arrow2csv.js`
     pass for `--help`, `-f <file>`, greedy `-s id name -f <file>`,
     and `--sep ' , '`


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to