Skip to content

Conversation

@ayuhito
Copy link

@ayuhito ayuhito commented Oct 14, 2025

Overview

Resolves #1135 using modern-tar. Around a 48MB --> 38MB reduction for package size which adds up a lot when considering download count. We're probably also a bit faster.

The next most impactful thing could be to reduce dependencies in dockerode, but they seem to be targeting node@8 so upping their limit to at least node@18 could help us start removing dependencies there.

image

Ref: https://npmgraph.js.org/?q=testcontainers

Please let me know if there are any concerns! I'm happy to look into it all!

@netlify
Copy link

netlify bot commented Oct 14, 2025

Deploy Preview for testcontainers-node ready!

Name Link
🔨 Latest commit d3320b7
🔍 Latest deploy log https://app.netlify.com/projects/testcontainers-node/deploys/68ef2dfd2826a60008f67a7f
😎 Deploy Preview https://deploy-preview-1161--testcontainers-node.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Comment on lines -414 to +418
expect((await container.exec(`stat -c "%a %n" /tmp/newdir/test.txt`)).output).toContain("777");
// Check directory permissions
expect((await container.exec(`stat -c "%a %n" /tmp/newdir`)).output).toContain("777");

// Verify files retain their original permissions
expect((await container.exec(`stat -c "%a %n" /tmp/newdir/test.txt`)).output).toContain("644");
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a bug/edge case from archiver, because node-tar and modern-tar do not mix directory modes and file modes together. That's not very standard behaviour.

Comment on lines +196 to +197
const data = content instanceof Readable ? await buffer(content) : content;
return { type: "content" as const, content: data, target, mode };
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

archiver implicitly buffers Readable. We're explicit here (and also maybe more efficient since we use Node native buffering).

@ayuhito ayuhito marked this pull request as ready for review October 14, 2025 16:53
@ayuhito
Copy link
Author

ayuhito commented Oct 14, 2025

I tried to validate as many tests as possible locally, but obviously this suite is very heavy so CI might fail if I didn't cover everything once these workflows are approved 🙈

@cristianrgreco cristianrgreco added enhancement New feature or request minor Backward compatible functionality labels Oct 14, 2025
@ayuhito ayuhito marked this pull request as draft October 15, 2025 02:40
@ayuhito ayuhito marked this pull request as ready for review October 15, 2025 02:56
Comment on lines +1 to +4
// Can be removed if testcontainers switches to ESM.
declare module "modern-tar/fs" {
export * from "modern-tar/dist/fs/index";
}
Copy link
Author

@ayuhito ayuhito Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

module: "commonjs" doesn't really support ESM only packages which use an export map. It can just read the old main import instead which is our browser specific export.

Alternatively, we could modernize the whole tsconfig stack. Then you could still export to CJS via something like tsdown. But this is the least-intrusive approach I can think of for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have a few dependencies which are ESM only, such as get-port, and it is enough to do an await import("get-port"). If modern-tar produces an export map then things should just work with TS without needing to add declarations

@cristianrgreco
Copy link
Collaborator

Hi @ayuhito, thanks for raising an excellent PR! Although I accept that the current dependency archiver is too heavyweight for our needs, I am hesitant in moving to a dependency which is just a few weeks old, as opposed to using archiver which is tried and tested. I'd happily accept a PR to use a dependency which is tried and tested (e.g. we have seen prompt releases for security vulnerabilities, has a large user base, proven to be responsive to issues, etc).

@ayuhito
Copy link
Author

ayuhito commented Oct 15, 2025

Hi @cristianrgreco, that is very reasonable and I can understand the tentativeness behind this change.

The reason I created this new package in the first place was that there was no reasonable lightweight alternative, but it definitely needs time to mature in the ecosystem. Although I would say I've done extensive work hardening the project and matching node-tar's extensive test suite. Maybe something to consider for the future then?

@cristianrgreco
Copy link
Collaborator

Maybe something to consider for the future then?

Definitely! Thanks again for raising the PR, hopefully will collaborate again soon 🙂

@ayuhito ayuhito closed this Oct 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request minor Backward compatible functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Replace archiver with lighter alternative

2 participants