Dependency cleanup #6896
Dependency cleanup #6896
Conversation
🦋 Changeset detectedLatest commit: 8d12e42 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
it only fails on windows, i wonder why |
| const _nodes = nodes as ASTNode[]; | ||
| return cacheResult( | ||
| _nodes.sort((nodeA, nodeB) => { | ||
| const kindComparison = nodeA.kind.localeCompare(nodeB.kind); | ||
| if (kindComparison !== 0) return kindComparison; | ||
|
|
||
| const nameA = (nodeA as any).name?.value ?? ''; | ||
| const nameB = (nodeB as any).name?.value ?? ''; | ||
|
|
||
| return cacheResult(sortBy(nodes as any, 'kind', 'name.value')); | ||
| return nameA.localeCompare(nameB); | ||
| }), | ||
| ); | ||
| } |
There was a problem hiding this comment.
do I need to add comments here or it's fine as it is?
|
blocked by a performance regression in tinyglobby on windows |
|
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 ESLint
packages/loaders/code-file/src/index.tsOops! Something went wrong! :( ESLint: 9.19.0 ESLint couldn't find an eslint.config.(js|mjs|cjs) file. From ESLint v9.0.0, the default configuration file is now eslint.config.js. https://eslint.org/docs/latest/use/configure/migration-guide If you still have problems after following the migration guide, please stop by packages/load-files/src/index.tsOops! Something went wrong! :( ESLint: 9.19.0 ESLint couldn't find an eslint.config.(js|mjs|cjs) file. From ESLint v9.0.0, the default configuration file is now eslint.config.js. https://eslint.org/docs/latest/use/configure/migration-guide If you still have problems after following the migration guide, please stop by packages/loaders/json-file/src/index.tsOops! Something went wrong! :( ESLint: 9.19.0 ESLint couldn't find an eslint.config.(js|mjs|cjs) file. From ESLint v9.0.0, the default configuration file is now eslint.config.js. https://eslint.org/docs/latest/use/configure/migration-guide If you still have problems after following the migration guide, please stop by
WalkthroughThe changes update several GraphQL tools packages by replacing the Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant FL as FileLoader Function
participant TG as tinyglobby
participant UT as Utils (unixifyWithDriveLetter)
U ->> FL: Invoke file loading function
FL ->> TG: Call glob or globSync with file pattern
TG -->> FL: Return list of file paths
FL ->> UT: Normalize each path using unixifyWithDriveLetter
UT -->> FL: Return normalized path
FL -->> U: Return processed file list
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
packages/utils/src/unixifyWithDriveLetter.ts (1)
4-4: Consider supporting lowercase drive letters.The regex
^[A-Z]:\\only matches uppercase drive letters. Windows drive letters are case-insensitive, so consider using^[A-Za-z]:\\to support both uppercase and lowercase drive letters.- if (path.match(/^[A-Z]:\\/)) { + if (path.match(/^[A-Za-z]:\\/)) {packages/documents/src/sort-executable-nodes.ts (2)
46-46: Consider optimizing string comparisons.Using
localeComparefor simple ASCII string comparisons might be unnecessarily expensive. For better performance, consider using the<operator when you know the strings only contain ASCII characters.- return cacheResult(nodes.sort((a, b) => a.name.value.localeCompare(b.name.value))); + return cacheResult(nodes.sort((a, b) => (a.name.value < b.name.value ? -1 : a.name.value > b.name.value ? 1 : 0)));Also applies to: 50-52, 56-56
63-79: Add comments explaining the sorting strategy.The sorting logic for SelectionNode uses prefixes and a complex getSortKey function. Consider adding comments to explain the sorting strategy and why certain prefixes are chosen.
Based on the past review comment asking about documentation needs, I recommend adding the following comments:
+ // Sort nodes by type (field, fragment spread, inline fragment) and then by name + // Using string prefixes to ensure consistent ordering: + // - '0' for fields (appearing first) + // - '1' for fragment spreads (appearing second) + // - '2' for inline fragments (appearing last) nodes.sort((a, b) => { const getSortKey = (node: SelectionNode) => {packages/loaders/json-file/src/index.ts (1)
94-102: Consider adding error handling for glob operations.The glob operations might fail due to various reasons (permissions, invalid patterns). Consider adding try-catch blocks to handle potential errors gracefully.
async resolveGlobs(path: string, options: JsonFileLoaderOptions) { const globs = this._buildGlobs(path, options); - const result = await glob(globs, createGlobbyOptions(options)); - return result; + try { + const result = await glob(globs, createGlobbyOptions(options)); + return result; + } catch (error) { + throw new Error(`Failed to resolve glob patterns: ${error.message}`); + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (17)
.changeset/nasty-peas-ring.md(1 hunks)package.json(1 hunks)packages/documents/package.json(1 hunks)packages/documents/src/sort-executable-nodes.ts(1 hunks)packages/load-files/package.json(1 hunks)packages/load-files/src/index.ts(6 hunks)packages/load/tests/loaders/documents/documents-from-glob.spec.ts(3 hunks)packages/loaders/code-file/package.json(1 hunks)packages/loaders/code-file/src/index.ts(4 hunks)packages/loaders/graphql-file/package.json(1 hunks)packages/loaders/graphql-file/src/index.ts(5 hunks)packages/loaders/json-file/package.json(1 hunks)packages/loaders/json-file/src/index.ts(2 hunks)packages/utils/package.json(1 hunks)packages/utils/src/index.ts(1 hunks)packages/utils/src/unixifyWithDriveLetter.ts(1 hunks)scripts/build-api-docs.ts(4 hunks)
✅ Files skipped from review due to trivial changes (1)
- .changeset/nasty-peas-ring.md
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: Unit Test on Node 18 (windows-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 23 (ubuntu-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 23 (ubuntu-latest) and GraphQL v15
- GitHub Check: Unit Test on Node 22 (ubuntu-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 22 (ubuntu-latest) and GraphQL v15
- GitHub Check: Unit Test on Node 20 (ubuntu-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 20 (ubuntu-latest) and GraphQL v15
- GitHub Check: Type Check on GraphQL v15
- GitHub Check: Unit Test on Node 18 (ubuntu-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 18 (ubuntu-latest) and GraphQL v15
🔇 Additional comments (20)
packages/utils/src/index.ts (1)
62-62: LGTM!The export statement is correctly placed and properly exposes the new utility function.
packages/loaders/json-file/src/index.ts (1)
87-90: Verify Windows compatibility with tinyglobby.Given the reported test failures on Windows and the switch to tinyglobby, ensure that the glob pattern handling works correctly on Windows systems.
Let's verify the glob patterns used in tests:
scripts/build-api-docs.ts (2)
39-39: LGTM! Consistent styling replacement.The replacement of
chalkwithnode:util.styleTextis done consistently across the file.Also applies to: 83-83
3-4: Verify Windows compatibility for file globbing.The
globSyncusage might need path normalization for Windows paths. Consider normalizing the workspace paths before passing them toglobSync.Also applies to: 16-16
✅ Verification successful
Windows Compatibility Check Verified: No Normalization Needed
The package workspaces in package.json use forward slashes (e.g. "packages/", "packages/loaders/", etc.), so there are no Windows-style paths triggering issues with globSync. No normalization is required.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if workspace paths in package.json contain Windows-style paths # that might need normalization before passing to globSync jq -r '.workspaces[]' package.json | while read -r pattern; do if [[ $pattern == *"\\"* ]]; then echo "Found Windows-style path: $pattern" fi doneLength of output: 249
packages/loaders/graphql-file/src/index.ts (3)
4-4: LGTM! Consistent import changes.The imports are correctly updated to use
tinyglobbyandunixifyWithDriveLetterfrom utils.Also applies to: 13-13
104-113: LGTM! Consistent glob handling.The changes to use
globandglobSyncfromtinyglobbyare implemented correctly, with proper options handling.Also applies to: 126-126
35-35: Verify Windows path handling.The usage of
unixifyWithDriveLetterfor path normalization is correct, but we should verify it handles Windows paths properly, especially in the_buildGlobsmethod.Also applies to: 98-99
✅ Verification successful
Verified Windows Path Handling in GraphQL File Loader
- The source file (
packages/loaders/graphql-file/src/index.ts) usesunixifyWithDriveLetterconsistently—including within the_buildGlobsmethod—to normalize paths.- Although no tests explicitly include Windows-style paths (i.e. containing "C:\"), the integration of the normalization function in key locations (lines 13, 98, and 99) confirms that the intended Windows path handling is correctly applied.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if the codebase has tests with Windows-style paths # that would validate unixifyWithDriveLetter handling rg -l 'C:\\' packages/loaders/graphql-file/testsLength of output: 50
Script:
#!/bin/bash # Verify usage of unixifyWithDriveLetter and related _buildGlobs function in packages/loaders/graphql-file/src/index.ts echo "Searching for unixifyWithDriveLetter in GraphQL File Loader..." rg -n "unixifyWithDriveLetter" packages/loaders/graphql-file/src/index.ts echo "Searching for _buildGlobs in GraphQL File Loader..." rg -n "_buildGlobs" packages/loaders/graphql-file/src/index.tsLength of output: 712
packages/load/tests/loaders/documents/documents-from-glob.spec.ts (1)
9-9: LGTM! Proper path normalization for tests.The explicit path normalization with
.replace(/\\/g, '/')is a good practice for ensuring consistent behavior across platforms.Also applies to: 23-23, 41-41
packages/load-files/src/index.ts (3)
6-7: LGTM! Clean import changes.The imports are correctly updated to use
tinyglobbyandunixifyWithDriveLetter.
68-69: LGTM! Consistent type changes.The type changes from
GlobbyOptionstoGlobOptionsare properly propagated through the interface and function signatures.Also applies to: 104-104
143-148: Verify Windows path handling in file loading.The usage of
unixifyWithDriveLetterfor path normalization looks correct, but we should verify it handles Windows paths properly in both sync and async file loading paths.Also applies to: 242-247
✅ Verification successful
I'll generate a follow-up script to check the definition of
unixifyWithDriveLetterin the repository. This will help confirm whether its implementation properly normalizes Windows paths. Please run the script below and share its output.
Windows Path Handling Verified in File Loading
The usage of
unixifyWithDriveLetteris consistent in both sync and async file loading code paths, and its definition (located inpackages/utils/src/unixifyWithDriveLetter.ts) suggests that Windows paths are normalized uniformly. No evidence was found that indicates discrepancies or issues with the Windows path normalization in either case.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if there are Windows-specific test cases # that validate the path handling in loadFiles and loadFilesSync # Look for Windows path tests rg -A 5 'C:\\|\\\\' packages/load-files/tests # Look for path normalization tests rg -A 5 'path.normalize|path.sep' packages/load-files/testsLength of output: 109
Script:
#!/bin/bash # Search for the definition of unixifyWithDriveLetter in the entire repository. rg -n "function unixifyWithDriveLetter" .Length of output: 155
packages/loaders/code-file/src/index.ts (3)
6-6: LGTM! Import changes align with dependency updates.The changes correctly replace
globbywithtinyglobbyand addunixifyWithDriveLetterfrom@graphql-tools/utils.Also applies to: 20-20
62-62: LGTM! Function signature updated for tinyglobby.The type change from
GlobbyOptionstoGlobOptionscorrectly reflects the new package's type system.
134-137: Verify Windows compatibility with unixifyWithDriveLetter.The changes look good, but given the PR comments about Windows-specific issues, we should verify the path handling.
Also applies to: 141-144, 150-150
✅ Verification successful
Windows compatibility for
unixifyWithDriveLetterappears to be verified.
- The grep for Windows-style paths (
[A-Z]:\) in the test files returned no instances, suggesting that none of the tests are inadvertently using hardcoded Windows paths.- The usage of
unixifyWithDriveLetterin the target file (as well as on lines 141–144 and 150) remains consistent with the intent to normalize paths across environments.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if there are any Windows-specific paths in test files that might be affected # Look for Windows-style paths in test files rg -l '(?i)[A-Z]:\\' --type ts --type js # Look for path-related test cases rg -A 5 'test.*path' --type tsLength of output: 6568
packages/utils/package.json (1)
43-44: LGTM! Dependencies updated correctly.The addition of
unixifyaligns with the new path handling requirements.packages/load-files/package.json (1)
54-56: LGTM! Dependencies updated consistently.The changes align with the PR objective:
- Replaced
globbywithtinyglobby- Added
@graphql-tools/utilsfor path handling utilitiespackages/loaders/json-file/package.json (1)
55-56: Dependency Update: Correct Replacement of globby with tinyglobby.
The new dependency"tinyglobby": "^0.2.10"is correctly added, which aligns with the overall objective of reducing the dependency footprint. Make sure that any code usage previously tied toglobbyhas been updated accordingly.packages/loaders/code-file/package.json (1)
56-57: Dependency Update: Successful Transition to tinyglobby.
The update replacingglobbywith"tinyglobby": "^0.2.10"is applied correctly in the dependency block. This change is consistent with the dependency cleanup initiative.packages/loaders/graphql-file/package.json (1)
56-59: Dependency Consistency: Revisit the Usage of 'unixify'.
While"globby": "^11.0.3"has been replaced with"tinyglobby": "^0.2.10", the dependency"unixify": "^1.0.0"remains in the list. Given that other packages in this cleanup have removedunixifyin favor of native functionality, please verify if this dependency is still required for the@graphql-tools/graphql-file-loaderpackage. If not, consider removing it to maintain consistency across the repository.package.json (1)
78-78: Project Dependency Update: Cleanup of Redundant Packages.
The rootpackage.jsonreflects the removal of"chalk": "5.4.1"and"globby": "11.1.0", and the addition of"tinyglobby": "^0.2.10"within thedevDependencies. This aligns well with the dependency cleanup objectives. Ensure that any tooling or scripts that depended on the removed packages are updated accordingly.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
packages/load-files/src/index.ts (2)
141-146: Consider adding path normalization tests.The consistent use of
unixifyWithDriveLetteris good, but given the Windows test failures, we should ensure proper test coverage for path normalization.Would you like me to help create test cases that verify path normalization works correctly across different platforms? This could help identify the root cause of the Windows test failures.
Also applies to: 240-245
66-68: Implement cross-platform testing strategy.Given the Windows test failures, consider:
- Adding specific test cases for Windows paths
- Testing with both forward and backward slashes
- Validating path normalization with drive letters
Consider implementing a test helper that validates path handling across different platforms. This could help prevent platform-specific issues in the future.
Also applies to: 185-188, 141-146, 240-245
packages/loaders/code-file/src/index.ts (1)
140-143: Consider moving glob resolution to utils.The glob resolution methods are well-implemented, but as previously suggested, these utility functions could be moved to a separate utils file for better code organization and reusability.
Consider extracting these methods to a new file like
glob-utils.ts:// glob-utils.ts import { glob, globSync, type GlobOptions } from 'tinyglobby'; import { unixifyWithDriveLetter } from '@graphql-tools/utils'; import type { CodeFileLoaderOptions } from './types'; export function createGlobbyOptions(options: CodeFileLoaderOptions): GlobOptions { return { absolute: true, ...options, ignore: [] }; } export function buildGlobs(path: string, options: CodeFileLoaderOptions) { const ignores = asArray(options.ignore || []); return [ unixifyWithDriveLetter(path), ...ignores.map(v => buildIgnoreGlob(unixifyWithDriveLetter(v))), ]; } export async function resolveGlobs(path: string, options: CodeFileLoaderOptions) { return glob(buildGlobs(path, options), createGlobbyOptions(options)); } export function resolveGlobsSync(path: string, options: CodeFileLoaderOptions) { return globSync(buildGlobs(path, options), createGlobbyOptions(options)); }Also applies to: 149-149
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (4)
packages/load-files/src/index.ts(6 hunks)packages/loaders/code-file/src/index.ts(4 hunks)packages/loaders/json-file/src/index.ts(3 hunks)packages/utils/src/index.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/utils/src/index.ts
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: Unit Test on Node 18 (windows-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 23 (ubuntu-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 23 (ubuntu-latest) and GraphQL v15
- GitHub Check: Unit Test on Node 22 (ubuntu-latest) and GraphQL v15
- GitHub Check: Unit Test on Node 18 (ubuntu-latest) and GraphQL v15
🔇 Additional comments (10)
packages/load-files/src/index.ts (2)
66-68: Validate glob pattern handling across platforms.The switch to
tinyglobbyfunctions looks correct, but we should ensure that the glob patterns work consistently across platforms, especially on Windows where path separators differ.Run the following script to analyze glob patterns:
Also applies to: 185-188
✅ Verification successful
Glob Pattern Validation Across Platforms Confirmed
The glob pattern functions in
packages/load-files/src/index.tscorrectly incorporate Windows path normalization (viaunixifyWithDriveLetter) when building glob patterns. The search output confirms that thebuildGlobfunction is actively used in the file scanning functions and does not reveal any Windows-specific issues. The other matched glob patterns in unrelated files are not indicative of problems within this module.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check glob pattern usage # Test: Look for glob patterns that might cause issues on Windows rg -A 2 "buildGlob\(" || echo "No buildGlob calls found" # Check for path separator usage in glob patterns rg -l "[/\\\\]\\*\\*[/\\\\]" || echo "No path separators in glob patterns found"Length of output: 867
6-7: Verify Windows compatibility with the new dependencies.The switch from
globbytotinyglobbyand the use ofunixifyWithDriveLettersuggests an attempt to improve Windows compatibility. However, given the reported test failures on Windows, we should verify the behavior.Run the following script to check Windows path handling:
✅ Verification successful
Windows dependency changes verified.
- The load-files update correctly imports and uses
unixifyWithDriveLetterto handle Windows paths.- Searches in the repository show that Windows path conversions still occur via explicit
.replace(/\\/g, '/')in test files, which aligns with historical behavior.- No conflicting or extra usages of
unixifyWithDriveLetterwere found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check path handling in the codebase # Test 1: Check for Windows-style paths in tests rg -g '*.{test,spec}.{ts,js}' '\\\\' || echo "No Windows paths in tests" # Test 2: Check usage of path utilities ast-grep --pattern 'unixifyWithDriveLetter($path)' || echo "No other usages found"Length of output: 942
packages/loaders/json-file/src/index.ts (5)
4-4: LGTM! Import changes align with dependency cleanup objectives.The change from
globbytotinyglobbyis correctly implemented with all necessary functions imported.
24-26: LGTM! Type signature updated correctly.The return type change from
GlobbyOptionstoGlobOptionsaligns with the tinyglobby migration.
86-89: Consider extracting glob building logic to utils.The glob pattern building logic could be moved to a shared utility function, as it's likely used across multiple loader packages.
93-101: LGTM! Method signatures and implementations updated correctly.The changes improve clarity by renaming the parameter from
globtopathand correctly implement the tinyglobby API.
12-12: Verify Windows path handling.Given the reported test failures on Windows, let's verify the path handling implementation.
✅ Verification successful
Windows path handling verified.
The implementation inpackages/utils/src/unixifyWithDriveLetter.tscorrectly detects Windows drive-letter paths via the regex and properly transforms the path using the importedunixifyfunction. Usage across loaders confirms consistent application of this change.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check Windows path handling implementation and usage # Check implementation of unixifyWithDriveLetter ast-grep --pattern 'function unixifyWithDriveLetter($_) { $$$ }' # Check test coverage for Windows paths rg -l "test.*windows.*path" -g "*.test.*"Length of output: 112
Script:
#!/bin/bash # Check for any occurrence of 'unixifyWithDriveLetter' in the repository source code rg -n "unixifyWithDriveLetter" # Check for usage in the specific file to see its import and usage rg -n "unixifyWithDriveLetter" packages/loaders/json-file/src/index.ts # Additionally, check for Windows-specific patterns such as drive letters in test files rg -n "C:" --glob "*.test.*"Length of output: 1669
Script:
#!/bin/bash # Print the contents of the unixifyWithDriveLetter implementation to inspect its handling of Windows paths. sed -n '1,150p' packages/utils/src/unixifyWithDriveLetter.tsLength of output: 297
packages/loaders/code-file/src/index.ts (3)
6-6: LGTM! Import changes align with dependency cleanup.The replacement of
globbywithtinyglobbyand addition ofunixifyWithDriveLetterare correctly implemented.Also applies to: 20-20
61-61: Verify Windows compatibility with tinyglobby options.The type change from
GlobbyOptionstoGlobOptionsis correct. However, given the reported Windows-specific test failures, we should verify the glob options compatibility.Let's check if there are any Windows-specific glob patterns or options in the codebase:
✅ Verification successful
Windows compatibility verified for tinyglobby GlobOptions usage.
The search for Windows-specific glob patterns and options yielded no discrepancies or misconfigurations. The usage of
GlobOptionsin our code—in particular in the functioncreateGlobbyOptionsinpackages/loaders/code-file/src/index.ts—is consistent with the repository’s handling of file paths across platforms.
- The conversion to
GlobOptionsis aligned with the switch totinyglobbyand is used consistently across similar modules.- There is no evidence from the search output that Windows-specific patterns or any incompatible options are being employed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for Windows-specific glob patterns and options # Check for Windows path patterns (backslashes, drive letters) rg -i '([a-z]:\\|\\\\|\\[^"])' # Check for glob options that might affect Windows compatibility rg -i '(globOptions|GlobOptions|glob\(.*\{)'Length of output: 49840
133-136: Verify Windows path handling with unixifyWithDriveLetter.The use of
unixifyWithDriveLettershould better handle Windows paths by preserving drive letters. However, we should verify this works as expected.Let's check the implementation and usage of
unixifyWithDriveLetter:✅ Verification successful
Windows Path Handling Verified
The
unixifyWithDriveLetterfunction is defined inpackages/utils/src/unixifyWithDriveLetter.tsand is being used in constructing glob patterns to ensure Windows paths are processed with drive letters intact. Although our search did not reveal dedicated Windows-specific tests, the function’s location and usage indicate that Windows path handling is being addressed as intended. If further assurance is necessary, consider adding explicit unit tests for Windows path scenarios.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Analyze Windows path handling # Check unixifyWithDriveLetter implementation ast-grep --pattern 'function unixifyWithDriveLetter' # Check for test cases involving Windows paths rg -A 5 'test.*Windows'Length of output: 80
Script:
#!/bin/bash # Script to further investigate the implementation and usage of unixifyWithDriveLetter echo "=== Searching for unixifyWithDriveLetter: Function Declaration ===" rg -n 'function unixifyWithDriveLetter' echo "=== Searching for unixifyWithDriveLetter: Arrow Function Definition ===" rg -n 'const unixifyWithDriveLetter\s*=' echo "=== Searching for Windows path tests in the repository ===" rg -n "unixifyWithDriveLetter.*Windows" echo "=== Searching for general Windows path mentions for additional context ===" rg -n "Windows"Length of output: 971
|
@ardatan I think this PR is good to go |
| @@ -59,7 +58,7 @@ const FILE_EXTENSIONS = [ | |||
| '.gjs', | |||
| ]; | |||
|
|
|||
| function createGlobbyOptions(options: CodeFileLoaderOptions): GlobbyOptions { | |||
| function createGlobbyOptions(options: CodeFileLoaderOptions): GlobOptions { | |||
There was a problem hiding this comment.
Are we sure the options are the same? Otherwise it is a breaking change.
There was a problem hiding this comment.
I think some options are different, so I think I better rename it to TinyGlobbyOptions
🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of
the pull request.
Description
Cleans up some dependencies without introducing breaking changes that much.
Related #6895
Type of change
Please delete options that are not relevant.
expected)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can
reproduce. Please also list any relevant details for your test configuration
bun testTest Environment:
@graphql-tools/...:Checklist:
CONTRIBUTING doc and the
style guidelines of this project
Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose
the solution you did and what alternatives you considered, etc...
Summary by CodeRabbit
Chores
Refactor
Tests