maorleger commented on issue #55:
URL: https://github.com/apache/arrow-js/issues/55#issuecomment-4626481994
Thanks for the response - I went ahead and created #441 as mitigation here.
I opted to keep `@types/node` in there as they really don't impact runtime
behavior and risks.
Would love some feedback on that!
Regarding `@swc/helpers`, I came away with a different conclusion about
where SWC actually runs in this repo, and I want to make sure I'm not missing
something on my end.
The published library and CLI are both compiled by gulp-typescript (TSC),
not SWC (I think? see gulp/typescript-task.js). A grep -r '@swc/helpers'
targets/ on a freshly built tree turns up zero matches in any .js/.mjs/.d.ts;
the only helper imports in the published output come from tslib which remains.
The one place SWC enters the picture is the dev-time bin shebangs that go
through `@swc-node/register/esm-register` (e.g. `bin/file-to-stream.ts`,
`bin/integration.ts`). That path keeps working with `@swc/helpers` in devDeps -
I verified by:
- removing it from dependencies
- deleting node_modules + the lockfile
- reinstalling
- running both the test suite and the dev shebangs end-to-end.
I believe (but correct me if I'm wrong) that SWC will inline any helpers
unless
[externalHelpers](https://swc.rs/docs/configuration/compilation#jscexternalhelpers)
is set to true.
If you can repro a case where the published artifacts need `@swc/helpers`
at runtime I'd love to see it, but otherwise I think this one is safe to keep
in devDeps 🙇
Again, thanks for looking!
--
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]
