Prefer .js over .ts causing over-eager rebuilds with watch mode with preserve-symlinks
- Dominant language
- Go
- Stars
- 40.1k
- Forks
- 1.3k
- PR merge metrics
- No merged PRs in 30d
Description
I'm having some problems with the 0.18.0 change to prefer js over ts files and how it interacts with the `preserveSymlinks` option? I'm experiencing these problems on the latest 0.19 version too.
From https://github.com/evanw/esbuild/issues/3019:
> Regarding monorepos with symlinks: Like node, esbuild defaults to using the real path of an input file as its identity. So if there are symlinks in node_modules that point outside of node_modules, the real path of any of those input files won't include node_modules. You can change that behavior with esbuild's [--preserve-symlinks](https://esbuild.github.io/api/#preserve-symlinks) setting. So I guess in that case esbuild's behavior would differ depending on the value of that setting, but by default esbuild would prefer .ts files over .js files in that case
This seems to be saying that when using symlinks, if `--preserve-symlinks` is false, there will be no concerns with the new ts vs js preference, however when true it is expected to cause problems?
My problem is that we have locally symlinked node modules that are shared between applications - in a structure a little like this:
```
folders:
shared/
services//shared -> ../../shared
services//package.json
{
...
"dependencies": {
"mySharedPackageName": "file:shared/mySharedPackageName"
}
}
```
Setting `preserveSymlinks: false` causes the build to fail due to missing packages, not just due to missing local packages, but any NPM dependency of a shared package (regardless of whether it's also local and shared or from NPM) causes esbuild to throw a "Could not resolve" error.
Setting `preserveSymlinks: true` causes the build to ignore any typescript changes after the initial build (e.g., once esbuild has generated the typescript files).
Is there currently any way to workaround this? E.g., tsconfig, or an option for esbuild itself? Would a change in project structure resolve this problem (while still allowing shared local packages)
Would you support detecting that the file exists outside of node_modules regardless of the `preserveSymlinks` setting, or a white/blacklist glob pattern option to prefer ts over js in certain cases?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the linked issue #3019 and reproduce the reported setup: a locally linked shared package, preserveSymlinks enabled or disabled, and watch mode after TypeScript changes. Compare dependency resolution and rebuild behavior in both configurations; done means shared-package dependencies resolve and TypeScript edits trigger rebuilds consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js, typescript
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100