chore:remove symlink for windows #9410
Conversation
github-actions
bot
added
package: vue-query
package: query-core
package: solid-query
package: query-persist-client-core
package: eslint-plugin-query
package: svelte-query
package: svelte-query-devtools
package: query-devtools
package: angular-query-experimental
package: angular-query-devtools-experimental
package: query-async-storage-persister
package: query-codemods
package: query-sync-storage-persister
package: solid-query-persist-client
package: svelte-query-persist-client
package: vue-query-devtools
package: solid-query-devtools
package: query-broadcast-client-experimental
package: react-query-next-experimental
labels
|
View your CI Pipeline Execution ↗ for commit 2af4646
☁️ Nx Cloud last updated this comment at |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9410 +/- ##
==========================================
+ Coverage 45.37% 45.39% +0.01%
==========================================
Files 207 208 +1
Lines 8277 8279 +2
Branches 1869 1864 -5
==========================================
+ Hits 3756 3758 +2
Misses 4080 4080
Partials 441 441 🚀 New features to boost your workflow:
|
| legacyConfig({ entry: ['src/*.ts'] }), | ||
| { | ||
| ...modernConfig({ entry: ['src/*.ts'] }), | ||
| external: ['typescript'], |
There was a problem hiding this comment.
In eslint-plugin-query, applying the parent-level esbuildPlugin settings directly caused build failures.
To address this, previous versions used a modified copy of scripts/getTsupConfig.js instead of the original.
Considering potential future changes to getTsupConfig, this issue needed to be handled.
Thus, scripts/getTsupConfig.js was imported using a relative path, and settings specific to eslint-plugin-query were added separately.
There was a problem hiding this comment.
thinking about this some more - we already have a package called query-test-utils that exports some utils for testing so that we don’t have to duplicate them for various adapters.
couldn’t we put the shared configs there too and just import them through the workspace dependency ?
|
Got it. Similar to method 2 in #9272. I'll implement it that way. |
|
Using symlinks makes it less likely for dependencies such as Vite to resolve to the wrong version as opposed to importing stuff outside the workspace. I often encountered this:
This is very time consuming and distracting. Perhaps using a dedicated package with its own dependencies will be a good solution but let's keep this in mind. I think the current symlinks are an elegant method to resolve dependencies such as Vite to the proper workspace version. It's been a while since I developed on Windows, but I think it supports symlinks very well on:
|
|
You're right. I'm also developing in a Windows environment, but I'm able to write code without issues by using WSL. However, if we keep the existing symlinks, we'll need to update the CONTRIBUTING.md document. A few people, including myself, have had problems when first trying to modify Tanstack Query's code on Windows. This seems to be a matter of choice:
|
This PR continues the context of #9346.
Resolved Windows symbolic link issue (#9272) across all packages.