Something is wrong with 3.14.0 (fails in a Linux Docker CI environment)

[kaiyoma]

Problem

Apologies in advance for the lack of detail here...

I'm trying to upgrade from 3.13.0 to 3.14.0 and encountering a critical error in our CI system. We use Jenkins along with k8s and Linux-based (Debian) Docker images. If I try to upgrade tsx - without changing anything else - some of our tsx-based commands fail, with no output of any kind. I have no idea what's happening here, but some change between 3.13.0 and 3.14.0 has really broken things.

If I run the new version on my (Windows 11) laptop, everything is fine. But builds on our Debian Docker images are failing consistently. No output, no error message. tsx is invoked, and then the pipeline fails.

Clearly I can't provide a repro for this, but I'm happy to try to get more info for you if you like. If you want me to run some debugging commands inside our Linux container, just let me know.

Expected behavior

tsx should continue to work.

Minimal reproduction URL

Not possible here. Please read the above description

Version

3.14.0

Node.js version

18.16.0

Package manager

pnpm

Operating system

Linux

Contributions

• I plan to open a pull request for this issue
• I plan to make a financial contribution to this project

[privatenumber]

Sorry, but to file a bug report, you have to prove that the bug exists in tsx.

Otherwise, you're basically asking others to do the leg work of investigating your issue and identifying a bug that may not potentially be in tsx. If you're open to offering compensation for this work, please review my sponsorship tiers: https://github.com/sponsors/privatenumber

Additionally, for me to investigate on your behalf, I'll need more detailed information and perhaps access to the environment where the issue occurs.

[kaiyoma]

Sorry, but to file a bug report, you have to prove that the bug exists in tsx.

Like I said, the only thing I changed was upgrading tsx. I think that's pretty definitive.

I'll need more detailed information and perhaps access to the environment where the issue occurs.

Access to the environment is impossible (this is a corporate enterprise environment). Like I said, I'm happy to provide more detailed information, but I need your guidance on what exactly to provide.

[kaiyoma]

@privatenumber Look, you even have a Unix-related commit in your change list since 3.13.0: #332

Assuming that maybe something is wrong with this commit, what information would you need from me to help troubleshoot this?

[privatenumber]

I understand you're frustrated, but do you really expect anyone to want to help someone with such an attitude?

Here are your options:

• Like every bug reporter in this project, you can investigate the problem and demonstrate that the bug is in tsx
• You can convince someone else to help you investigate, either by paying them or by being a lot nicer

In either case, you should get rid of your entitlement because no one likes to help rude people.

Locking thread, but feel free to open a new issue once you can demonstrate the bug.

[privatenumber]

RE: Your comment in #​352

I think I am running into this problem as well. I reported it here (#363) and offered to help but the author is being very combative for some reason.

I am also seeing this problem in a Linux CI environment and I'm also seeing the issue with 3.14.0. I also cannot reproduce locally (only in CI).

In my case, I don't get any error output, which would be useful. Instead, there's no output at all and then the CI pipeline fails.

I understand your frustration with the situation. However, I removed your comment because it was speculative (no errors and can't reproduce) and didn't add to the conversation. If anything, it seemed you were attempting to stir up trouble, especially with your second sentence.

Please refrain from attempting to bypass the locked thread by responding to other issues.

---

I think I am running into this problem as well. I reported it here (#363)

You didn't report that problem here—you don't mention any errors or provide any information. And based on your comment above, you're not certain it's the same issue.

In contrast, #​352 provides extensive information, including a CI link and a stack trace, which substantiates the error being in tsx. It's clear they're investing effort to prove the bug rather than seeking free guidance.

and offered to help but the author is being very combative for some reason.

"offer to help" is a strange perspective. To be clear, you're seeking help.

I apologize if my response came off as combative. However, you're "offering help" to identify a bug that you cannot prove exists, and I'm declining that offer. Please respect that and move on.

If it wasn't clear why I closed this issue, it's because a minimal reproduction wasn't provided, and the request seemed to seek debugging support. This platform is for reporting bugs; please seek assistance elsewhere. Also, please recognize that everyone here is putting in the work to substantiate their bug reports, and no one is above that.

Subsequently, I locked the issue because of baseless accusations towards tsx and repeated attempts to push the conversation toward seeking free support.

I hope you understand. I'm happy to work together to address this as long as you can demonstrate the issue is in tsx.