Patch/v1.1.10 #12
Merged
Patch/v1.1.10 #12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Added the new `logDebugInfo` method to log all debugging information to the Output channel. - Extracted all the debug logging from the `constructor` into it's own method to keep the constructor clean. - Changed the format of the data logged for the supported languages. Instead of logging the `Map`s, we now utilise the auto-generated language definitions files. This is because the single-line languages are reformatted in a human-readable way to output to the file, so it would be better reading this formatted file than the JS `Map`.
This is a work around for the fact that the `vscode.extensions.all` API can't find any built-in extensions on the Windows-side when running in WSL. It only gets the WSL-installed extensions, which caused the extension not to work in #6 There is an open issue and a proposed API change in the sourcecode since 2022, but hasn't been released as a public API. See microsoft/vscode#145307 for more info. Added: - Added new `getExtensionsPathsFromWslEnv` method to retrieve the Windows built-in and user extensions paths from the environment variables when running in WSL. - Added new `readExtensionsFromDirectory` method to read the extensions paths and retrieve each extension data. Changed: - Changed `findAllLanguageConfigFilePaths` method to check if the extension is running in WSL. If it `isWsl`, then it calls the new `getExtensionsPathsFromWslEnv` method to get the paths, and uses the new `readExtensionsFromDirectory` to obtain the extensions data. We construct a new `extensions` array with all the windows-installed built-in and user extensions and also the WSL-installed extensions via `vscode.extensions.all`. (The extension will still work on Windows without WSL due to it using `vscode.extensions.all` outside of the `isWsl` check.) - Changed the `for...of` loop to iterate through the new `extensions` array.
Added: - Added an `isWsl` check, and uses the new `getExtensionsPathsFromWslEnv` method to log the Windows extensions paths from WSL. Changed: - Refactored all "VS Code" items into a new object so that we're not repeating "VS Code" multiple times. This makes for a better reading experience.
Added:
- Added new `extensionDetails` private property in `Configuration` as a Map object.
- Added new `setExtensionData` method to set the data into the `extensionDetails` Map. Also added its method call into the `constructor`.
- Added new `getExtensionData` public method to get the value of a specified key from the `extensionDetails` Map.
Changed:
- Refactored `getExtensionNames` to be more generic.
This will be used in the new `setExtensionData` method to get and set the names, id and version into the `extensionDetails` Map.
- Changed the name to `getExtensionPackageJsonData`.
- Changed it's visibility to `private`.
- Changed the reading of the package.json file to use the `readJsonFile` method as it does the exact same thing, and makes it DRYer.
- Added the extension's version.
- Changed all references to the old `getExtensionNames` method to use the new `getExtensionData` method with the specific key needed.
Removed:
- Removed the unused `extensionNames` variable and method call from the `getExtensionsPathsFromWslEnv` method.
Previously we manually created the user extensions path from the home directory env variables and concatenated strings on to it. This is only good if the default extensions directory is used. This will fail if the user has changed the directory location with the CLI `code --extensions-dir <path>` So to fix, we're now getting the user extensions path from where ever this extension is located. The code for this is defined in `setExtensionData` method as committed in 25fab48. - Changed the construction of the users extensions path in `logDebugInfo` to use the `getExtensionData` method to get the path. - Removed the unneeded home directory variables.
- Moved the code to get the built-in extensions path from `logDebugInfo` in to the `setExtensionData` method. - Added the built-in extensions path to the `extensionDetails` Map in `setExtensionData` method. - Updated `logDebugInfo` method to get the `builtInExtensionsPath` key from the Map using `getExtensionData` method.
Added:
- Added the WSL built-in and user extensions paths code to the `setExtensionData` method and set them into the `extensionDetails` with new Map keys.
- Moved the environment variable code to get the WSL-installed user extensions path from the `logDebugInfo` method, and added the `getExtensionData` method call to the log item instead.
- Refactored the `getExtensionsPathsFromWslEnv` method into `setExtensionData` method, simplifying the code.
Removed:
- Removed the now unused `getExtensionsPathsFromWslEnv` method, and changed all references to use the `getExtensionData` with the appropriate key.
This was
linked to
issues
Jul 12, 2025
Closed
- Moved utility functions to a new `utils` file for better organisation and reusability between files.
- `readJsonFile`
- `writeJsonFile`
- `reconstructRegex`
- `convertMapToReversedObject`
- Changed all references to these functions to use the new namespace `utils` import.
- Added a new `ensureDirExists` utility function to create specified directory if it doesn't exist. - Moved the "directory exists" code in the `writeJsonFile` util function to the new function, but making it for generic use (removed references to the auto-generated directory). - Added the new function call into the `Configuration::writeCommentLanguageDefinitionsToJsonFile` method to ensure the auto generated dir exists.
…nction
- Refactored `mergeConfigProperty` into a new generic `mergeArraysBy` utility function.
- Removed `mergeConfigProperty` method from `Configuration` class.
- Added new `mergeArraysBy` utility function in `utils` file, and updated the code to be more generic with better typings.
- Replaced all references to the old method in `Configuration` with the new utils function.
Changed:
- Moved `getExtensionPackageJsonData`, `setExtensionData`, `getExtensionData` methods into a new `ExtensionData` class for simplicity and better organisation.
- Simplified the `getExtensionPackageJsonData` method to get all package.json data not just a select few.
By using the new type `IPackageJson`, we can properly type the data as package.json instead of a generic `object` or `any`.
- Changed the `name` variable to `namespace`, simplied it's code and added it to the `contributes.configuration` object of the packageJson data, since it's the namespace of the settings
- Changed the `name` variable to `namespace`, simplied it's code and added it to the `contributes.configuration` object of the packageJson data, since it's the namespace of the configuration settings.
- Split `setExtensionData` into 2 methods: `setExtensionData` and `createExtensionData`; and simplified the code.
- `createExtensionData` to create the extension data object, defining the keys and values for the Map. The keys as defined here will also be used for type inference for VScode intellisense in the new `get` method.
- `setExtensionData` to set the data as defined in `createExtensionData` method into the `extensionData` Map.
- Changed all references to the old `getExtensionData` method to use the `get` method of the new `ExtensionData` class.
- Renamed the `Configuration` property `extensionDetails` to `extensionData`; and instantiate the `ExtensionData` class as it's value.
Added:
- Added new `get` method to get the extension's data by a specified key.
VScode intellisense auto-suggests the keys by using type inference from the keys set in `createExtensionData` method. This is important so remembering or looking up the keys isn't a pain.
- Added `getAll` method to get all extension data as readonly so it can only be logged in the Output Channel.
- Added a new dependency `package-json-type` to allow package.json typings as `IPackageJson`.
VS Code's `extensions.all` API only gets enabled extensions and doesn't include disabled ones, which could prevent language configs being found. To fix, we completely remove getting the extensions from the vscode API, and instead get the extensions directly from the directories. - Added the ability to get the built-in and user extensions directly from the directory on non-WSL systems (eg. Windows), but using the same way it gets extensions on WSL using the extension data path keys and `readExtensionsFromDirectory` method. - Removed `vscode.extensions.all` API call from `findAllLanguageConfigFilePaths` method.
https://github.com/yCodeTech/auto-comment-blocks/actions/runs/16339281667/job/46157703386?pr=12 This error occurs because testing used a hard-coded path to simulate what the `vscode.extensions.getExtension().extensionPath` API would get. Since commit b0a40aa changed the way we get/set the package.json data, this was just an oversight. Since we're already using the path of the extension to get the package.json in `getExtensionPackageJsonData`, we can just leverage this, and properly integrate the path. Fixed by: - Adding the extension path as a new `extensionPath` key in the `packageJSON` data object. - Completely removing the VS Code's `.extensions.getExtension()` API call in `createExtensionData` method and changing it to use the `extensionPath` key in the `packageJsonData` property.
- Added the new `logDebugInfo` method to log all debugging information to the Output channel. - Extracted all the debug logging from the `constructor` into it's own method to keep the constructor clean. - Changed the format of the data logged for the supported languages. Instead of logging the `Map`s, we now utilise the auto-generated language definitions files. This is because the single-line languages are reformatted in a human-readable way to output to the file, so it would be better reading this formatted file than the JS `Map`.
This is a work around for the fact that the `vscode.extensions.all` API can't find any built-in extensions on the Windows-side when running in WSL. It only gets the WSL-installed extensions, which caused the extension not to work in #6 There is an open issue and a proposed API change in the sourcecode since 2022, but hasn't been released as a public API. See microsoft/vscode#145307 for more info. Added: - Added new `getExtensionsPathsFromWslEnv` method to retrieve the Windows built-in and user extensions paths from the environment variables when running in WSL. - Added new `readExtensionsFromDirectory` method to read the extensions paths and retrieve each extension data. Changed: - Changed `findAllLanguageConfigFilePaths` method to check if the extension is running in WSL. If it `isWsl`, then it calls the new `getExtensionsPathsFromWslEnv` method to get the paths, and uses the new `readExtensionsFromDirectory` to obtain the extensions data. We construct a new `extensions` array with all the windows-installed built-in and user extensions and also the WSL-installed extensions via `vscode.extensions.all`. (The extension will still work on Windows without WSL due to it using `vscode.extensions.all` outside of the `isWsl` check.) - Changed the `for...of` loop to iterate through the new `extensions` array.
Added: - Added an `isWsl` check, and uses the new `getExtensionsPathsFromWslEnv` method to log the Windows extensions paths from WSL. Changed: - Refactored all "VS Code" items into a new object so that we're not repeating "VS Code" multiple times. This makes for a better reading experience.
Added:
- Added new `extensionDetails` private property in `Configuration` as a Map object.
- Added new `setExtensionData` method to set the data into the `extensionDetails` Map. Also added its method call into the `constructor`.
- Added new `getExtensionData` public method to get the value of a specified key from the `extensionDetails` Map.
Changed:
- Refactored `getExtensionNames` to be more generic.
This will be used in the new `setExtensionData` method to get and set the names, id and version into the `extensionDetails` Map.
- Changed the name to `getExtensionPackageJsonData`.
- Changed it's visibility to `private`.
- Changed the reading of the package.json file to use the `readJsonFile` method as it does the exact same thing, and makes it DRYer.
- Added the extension's version.
- Changed all references to the old `getExtensionNames` method to use the new `getExtensionData` method with the specific key needed.
Removed:
- Removed the unused `extensionNames` variable and method call from the `getExtensionsPathsFromWslEnv` method.
Previously we manually created the user extensions path from the home directory env variables and concatenated strings on to it. This is only good if the default extensions directory is used. This will fail if the user has changed the directory location with the CLI `code --extensions-dir <path>` So to fix, we're now getting the user extensions path from where ever this extension is located. The code for this is defined in `setExtensionData` method as committed in 25fab48. - Changed the construction of the users extensions path in `logDebugInfo` to use the `getExtensionData` method to get the path. - Removed the unneeded home directory variables.
- Moved the code to get the built-in extensions path from `logDebugInfo` in to the `setExtensionData` method. - Added the built-in extensions path to the `extensionDetails` Map in `setExtensionData` method. - Updated `logDebugInfo` method to get the `builtInExtensionsPath` key from the Map using `getExtensionData` method.
Added:
- Added the WSL built-in and user extensions paths code to the `setExtensionData` method and set them into the `extensionDetails` with new Map keys.
- Moved the environment variable code to get the WSL-installed user extensions path from the `logDebugInfo` method, and added the `getExtensionData` method call to the log item instead.
- Refactored the `getExtensionsPathsFromWslEnv` method into `setExtensionData` method, simplifying the code.
Removed:
- Removed the now unused `getExtensionsPathsFromWslEnv` method, and changed all references to use the `getExtensionData` with the appropriate key.
- Moved utility functions to a new `utils` file for better organisation and reusability between files.
- `readJsonFile`
- `writeJsonFile`
- `reconstructRegex`
- `convertMapToReversedObject`
- Changed all references to these functions to use the new namespace `utils` import.
- Added a new `ensureDirExists` utility function to create specified directory if it doesn't exist. - Moved the "directory exists" code in the `writeJsonFile` util function to the new function, but making it for generic use (removed references to the auto-generated directory). - Added the new function call into the `Configuration::writeCommentLanguageDefinitionsToJsonFile` method to ensure the auto generated dir exists.
…nction
- Refactored `mergeConfigProperty` into a new generic `mergeArraysBy` utility function.
- Removed `mergeConfigProperty` method from `Configuration` class.
- Added new `mergeArraysBy` utility function in `utils` file, and updated the code to be more generic with better typings.
- Replaced all references to the old method in `Configuration` with the new utils function.
Changed:
- Moved `getExtensionPackageJsonData`, `setExtensionData`, `getExtensionData` methods into a new `ExtensionData` class for simplicity and better organisation.
- Simplified the `getExtensionPackageJsonData` method to get all package.json data not just a select few.
By using the new type `IPackageJson`, we can properly type the data as package.json instead of a generic `object` or `any`.
- Changed the `name` variable to `namespace`, simplied it's code and added it to the `contributes.configuration` object of the packageJson data, since it's the namespace of the settings
- Changed the `name` variable to `namespace`, simplied it's code and added it to the `contributes.configuration` object of the packageJson data, since it's the namespace of the configuration settings.
- Split `setExtensionData` into 2 methods: `setExtensionData` and `createExtensionData`; and simplified the code.
- `createExtensionData` to create the extension data object, defining the keys and values for the Map. The keys as defined here will also be used for type inference for VScode intellisense in the new `get` method.
- `setExtensionData` to set the data as defined in `createExtensionData` method into the `extensionData` Map.
- Changed all references to the old `getExtensionData` method to use the `get` method of the new `ExtensionData` class.
- Renamed the `Configuration` property `extensionDetails` to `extensionData`; and instantiate the `ExtensionData` class as it's value.
Added:
- Added new `get` method to get the extension's data by a specified key.
VScode intellisense auto-suggests the keys by using type inference from the keys set in `createExtensionData` method. This is important so remembering or looking up the keys isn't a pain.
- Added `getAll` method to get all extension data as readonly so it can only be logged in the Output Channel.
- Added a new dependency `package-json-type` to allow package.json typings as `IPackageJson`.
VS Code's `extensions.all` API only gets enabled extensions and doesn't include disabled ones, which could prevent language configs being found. To fix, we completely remove getting the extensions from the vscode API, and instead get the extensions directly from the directories. - Added the ability to get the built-in and user extensions directly from the directory on non-WSL systems (eg. Windows), but using the same way it gets extensions on WSL using the extension data path keys and `readExtensionsFromDirectory` method. - Removed `vscode.extensions.all` API call from `findAllLanguageConfigFilePaths` method.
https://github.com/yCodeTech/auto-comment-blocks/actions/runs/16339281667/job/46157703386?pr=12 This error occurs because testing used a hard-coded path to simulate what the `vscode.extensions.getExtension().extensionPath` API would get. Since commit b0a40aa changed the way we get/set the package.json data, this was just an oversight. Since we're already using the path of the extension to get the package.json in `getExtensionPackageJsonData`, we can just leverage this, and properly integrate the path. Fixed by: - Adding the extension path as a new `extensionPath` key in the `packageJSON` data object. - Completely removing the VS Code's `.extensions.getExtension()` API call in `createExtensionData` method and changing it to use the `extensionPath` key in the `packageJsonData` property.
…ment-blocks into patch/v1.1.10
Languages defined in the `disabledLanguages` setting are not being disabled for certain things, and are still being treated as "supported". Disabled languages should not be in any "supported" list, auto or custom supported. Fixed by ensuring in all cases the langId will be ignored if it's set as disabled. - Added `isLangIdDisabled` method calls to all single-line comments and multi-line comments for both auto-supported and custom-supported lists.
- Update auto-supported definition files for the VScode default languages. - Remove custom-supported languages. - Added links to the definition files in README to view all auto-supported VScode default languages.
Due to some extensions either not specifying all the language configuration properties in the file or setting the comment properties to an empty array (like the "stillat-llc.vscode-antlers" extension does which overrides the HTML config and makes the comments not work without the extension activated), we need to ensure that they are merged with other possible configs for the language. - Changed `languageConfigFilePaths` Map to accept an array value instead of just a single string. - Changed `findAllLanguageConfigFilePaths` method to set the config path into an array as the value in `languageConfigFilePaths` Map, and to push a new path into the array if the `langId` key already exists in the Map. - Changed `setLanguageConfigDefinitions` method to allow it to loop through the new array of paths which sets the configs into the `languageConfigs` Map, and if the `langId` key already exists then merge the existing config with the new config. This merges the comments from both configs together and skips empty arrays. It also merges all other config properties together to ensure we are getting a full language configuration. By merging all available configs for the language, the language won't have any issues regarding malformed configs, or comments not working.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bug Fixes and Enhancements:
New Features:
cmd+shift+mkeybinding for Blade override comments on macOS.is-wslfor WSL detection andpackage-json-typefor TypeScript type definitions of package.json objects.Codebase Refactoring:
ExtensionDataclass for centralized management of extension metadata, improving maintainability and debugging.utils.tsfile for better code reuse.These changes collectively enhance the extension's functionality, usability, and maintainability while addressing key user-reported issues.