-
-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: tsconfig.json
edge-cases in dependencies
#377
fix: tsconfig.json
edge-cases in dependencies
#377
Conversation
Thanks for the PR! RE: fix(dev): prevent fs-fixture causing a re-run loop Can you provide env details? (OS, tooling versions, etc) I haven't needed this before. |
Sure thing! OS: It might well be a linux thing (happy to rebase without that commit), but here's what the problem looked like for me in case it gives any additional insight |
b95fd2b
to
6868a2e
Compare
I removed the commit that introduced the |
src/loader.ts
Outdated
@@ -81,6 +81,12 @@ async function ESBuildLoader( | |||
} else { | |||
/* Detect tsconfig file */ | |||
|
|||
// Don't look for tsconfig.json based on external sources (see | |||
// https://github.com/privatenumber/esbuild-loader/issues/363) | |||
if (resourcePath.match(/node_modules/) !== null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (resourcePath.match(/node_modules/) !== null) { | |
if (resourcePath.includes('/node_modules/')) { |
This could catch something like node_modules_file
. I'm wondering if my suggestion would work on Windows where they use blackslashes... the tests will tell
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point, thanks for catching this! In the latest commit, I changed the search a little and hopefully the path.sep
tactic means it is a little more portable
tests/specs/tsconfig.ts
Outdated
// Fake external dependency | ||
node_modules: { | ||
'fake-lib': { | ||
'index.js': 'export function testFn() { return "Hi!" }', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make this a .ts
file to confirm TS files in node_modules can still be compiled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
Sorry about the linting/type-check errors. I fixed them in the It looks like this PR no longer compiles TS in node_modules, but we actually still want to compile them. To do this, we'll probably try to read the tsconfig.json file, but we should ignore any tsconfig errors in |
Thanks! I'd completely changed the behaviour without realising by using that early return statement. I've pushed a change which should still try to apply the transform and log a warning if the tsconfig fails to load for some reason. In short, it shouldn't change any behaviour except for when the tsconfig fails to resolve specifically for resources somewhere in node_modules
Never mind that, they're now |
c8c8668
to
14e606f
Compare
(fyi; squashed/rebased for a tidier history - no other changes) |
src/loader.ts
Outdated
this.emitWarning( | ||
new Error(`[esbuild-loader] Error while discovering tsconfig.json in dependency: "${error?.toString()}"`), | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to log more by default for cases such as these, but I'd defer to your preference as the maintainer of the project. Do you think there's value in logging this, or would it be preferable to silently ignore it?
For the original issue that sparked this PR, I don't think it would be a directly actionable warning but may provide a breadcrumb if someone is debugging an unusual output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a good idea. I would appreciate it as a user.
For the original issue, I think the warning should direct the users to report bugs to the appropriate repo.
I'll update the error message in get-tsconfig
to be more specific about which file it's trying to resolve.
Original issue: privatenumber#363, esbuild-loader would attempt to resolve typescript configs for external sources under some conditions, and cause problems (in this case, the resolved tsconfig.json referenced a config that is not in the dependency tree and thus unresolvable) tsconfig fix: warn on tsconfig resolution error, continue transform
14e606f
to
5a31cd4
Compare
I made several changes:
|
tsconfig.json
parsing edge-cases in dependencies
tsconfig.json
parsing edge-cases in dependenciestsconfig.json
edge-cases in dependencies
🎉 This issue has been resolved in version 4.2.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Thanks for the PR and collaboration @glsignal! Appreciate your contribution 🙏 |
Thank you for the support and pushing it over the finish line @privatenumber! Great collab 😄 |
Fixes #363 where esbuild-loader would resolve the tsconfig.json of external files under certain conditions, which most recently became a problem when one of these configs included an
extends
option that referenced a package not in the project's dependency tree, making it impossible to resolve.The patch changes this behaviour and will attempt to resolve the tsconfig.json still, however when it encounters a problem, if the resource associated with the tsconfig is a third party dependency, it will suppress the error and log a warning instead of bailing.