[Enhancement] Reduce dependencies.

[MicahZoltu]

ts-patch:

ttypescript:

Unfortunately, ttypescript appears to be unmaintained and broken with declarationMap: true, but I'm very loath to bring in 35 dependencies to replace 1.

Is there any chance of getting the number of dependencies down to something much smaller (e.g., 0-5 total)?

[juanrgm]

Perhaps one of the reasons why it was abandoned was due to the extra cost of not having dependencies.

[nonara]

Hello. Thanks for the request.

I have two points I'd make on that.

First, the library was built to have an incredibly light footprint, which it does. While it may look like a bit, its memory size is small and overall, it's substantially less than most libraries would be.

Second, I would remind that this a development dependency. Relative to most like it, it is very light.

That said, however, I would be happy to replace what we can. Some which would be great to replace would be:

• global-prefix
• shelljs (should be easily replaced at this point)
• resolve (maybe, we'd need to be sure that there are no side effects)

I would welcome PRs to reduce the footprint.

[MicahZoltu]

Just for clarity (not to pressure): My primary concern with the large dependency tree isn't memory footprint or bandwidth required, but rather security. There have been a number of supply chain attacks in the JavaScript ecosystem, and any dependency (direct or transitive) is a potential attack vector. The more dependencies there are, the more maintainers there are, and the more maintainers there are the more the opportunity for one of them to do something malicious or one of them to lose access to their account to an attacker.

A tool like this would likely be installed as part of CI, and if one can get code executing on the CI server you have the ability to do basically whatever you want. There are things one can do to mitigate these attacks like using npm ci instead of npm install, but it is easy to forget and do npm install instead and open yourself up, so a defense in depth strategy is preferred.

[nonara]

That's a good point. I believe a good strategy would be to replace what we can with local logic and we could use Webpack to bundle the rest for release.

If you or anyone want to get a PR going, I'd be happy to tag in to help where I can.

Notes for future work

• chalk & strip-ansi can be replaced by internal functions to wrap with colour codes only if colour mode is enabled

[nonara]

Going ahead and closing this for now. The new version dropped some deps, but they're not entirely eliminated.

A part of the roadmap for the next major version will be to use esbuild, however, which should alleviate some concerns.