salesforce
diff --git a/‎.github/ISSUE_TEMPLATE/Bug_report.md
+1-1 b/‎.github/ISSUE_TEMPLATE/Bug_report.md
+1-1
diff --git a/‎.github/PULL_REQUEST_TEMPLATE.md
+4-4 b/‎.github/PULL_REQUEST_TEMPLATE.md
+4-4
diff --git a/‎CODE_OF_CONDUCT.md
+14-14 b/‎CODE_OF_CONDUCT.md
+14-14
diff --git a/‎CONTRIBUTING.md
+36-36 b/‎CONTRIBUTING.md
+36-36
diff --git a/‎package.json
+14-14 b/‎package.json
+14-14
diff --git a/‎packages/@lwc/babel-plugin-component/README.md
+17-17 b/‎packages/@lwc/babel-plugin-component/README.md
+17-17
@@ -42,7 +42,7 @@ versions < 0.17: "lwc-engine": "0.16.8"
 versions >= 0.17: "lwc-engine": "0.17.2"
 -->
 
--   LWC: x.x.x
+- LWC: x.x.x
 
 **Possible Solution**
 
 
@@ -13,8 +13,8 @@
     Remove the incorrect item for the list.
 -->
 
--   😮‍💨 No, it does not introduce a breaking change.
--   💔 Yes, it does introduce a breaking change.
+- 😮‍💨 No, it does not introduce a breaking change.
+- 💔 Yes, it does introduce a breaking change.
 
 <!-- If yes, please describe the impact and migration path for existing applications. -->
 
@@ -33,8 +33,8 @@
     Remove the incorrect item from the list.
 -->
 
--   🤞 No, it does not introduce an observable change.
--   🔬 Yes, it does include an observable change.
+- 🤞 No, it does not introduce an observable change.
+- 🔬 Yes, it does include an observable change.
 
 <!-- If yes, please describe the anticipated observable changes. -->
 
 
@@ -35,23 +35,23 @@ socioeconomic status, or other similar personal characteristics.
 Examples of behavior that contributes to creating a positive environment
 include:
 
--   Using welcoming and inclusive language
--   Being respectful of differing viewpoints and experiences
--   Gracefully accepting constructive criticism
--   Focusing on what is best for the community
--   Showing empathy toward other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy toward other community members
 
 Examples of unacceptable behavior by participants include:
 
--   The use of sexualized language or imagery and unwelcome sexual attention or
-    advances
--   Personal attacks, insulting/derogatory comments, or trolling
--   Public or private harassment
--   Publishing, or threatening to publish, others' private information—such as
-    a physical or electronic address—without explicit permission
--   Other conduct which could reasonably be considered inappropriate in a
-    professional setting
--   Advocating for or encouraging any of the above behaviors
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Personal attacks, insulting/derogatory comments, or trolling
+- Public or private harassment
+- Publishing, or threatening to publish, others' private information—such as
+  a physical or electronic address—without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+- Advocating for or encouraging any of the above behaviors
 
 ## Our Responsibilities
 
 
@@ -2,18 +2,18 @@
 
 We want to encourage the developer community to contribute to Lightning Web Components. This guide has instructions to install, build, test and contribute to the framework.
 
--   [Requirements](#requirements)
--   [Installation](#installation)
--   [Building LWC](#building-lwc)
--   [Testing](#testing)
--   [Git Workflow](#git-workflow)
+- [Requirements](#requirements)
+- [Installation](#installation)
+- [Building LWC](#building-lwc)
+- [Testing](#testing)
+- [Git Workflow](#git-workflow)
 
 Before you start, familiarize yourself with [Lightning Web Components](https://lwc.dev/guide/introduction).
 
 ## Requirements
 
--   [Node](https://nodejs.org/)
--   [Yarn](https://yarnpkg.com/)
+- [Node](https://nodejs.org/)
+- [Yarn](https://yarnpkg.com/)
 
 This project uses [Volta](https://volta.sh/) to ensure that all the contributors share the same version of `Node` and `Yarn` for development. If you are considering making frequent contributions to this project, we recommend installing this tool as well. Otherwise, check the `volta` field in `package.json` to see which versions to use.
 
@@ -94,8 +94,8 @@ Test fixtures are file-based tests that are executed using a helper called [`tes
 
 When developing LWC, use integration testing to ensure functionality is correctly reflected in the browser. This repo has two integration test suites.
 
--   @lwc/integration-karma: Contains all integration tests that can run with javascript only. For information about usage and contribution, refer to this [documentation][integration-karma-readme].
--   @lwc/integration-tests: Contains all other integration tests that require web driver API support (e.g., focus, keyboard navigation). For information about usage and contribution, refer to this [documentation][integration-test-readme].
+- @lwc/integration-karma: Contains all integration tests that can run with javascript only. For information about usage and contribution, refer to this [documentation][integration-karma-readme].
+- @lwc/integration-tests: Contains all other integration tests that require web driver API support (e.g., focus, keyboard navigation). For information about usage and contribution, refer to this [documentation][integration-test-readme].
 
 To run the Karma tests from the root:
 
@@ -132,7 +132,7 @@ This will check that the minified bundle sizes don't exceed our thresholds. Our
 
 LWC relies on type annotations.
 
--   Make sure your editor supports [typescript](https://www.typescriptlang.org/).
+- Make sure your editor supports [typescript](https://www.typescriptlang.org/).
 
 ### ESLint
 
@@ -297,36 +297,36 @@ If the commit reverts a previous commit, it should begin with `revert: `, follow
 
 Must be one of the following:
 
--   **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
--   **chore**: Other changes that don't modify src or test files
--   **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
--   **docs**: Documentation only changes
--   **feat**: A new feature
--   **fix**: A bug fix
--   **perf**: A code change that improves performance
--   **refactor**: A code change that neither fixes a bug nor adds a feature
--   **revert**: Reverts a previous commit
--   **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
--   **test**: Adding missing tests or correcting existing tests
+- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+- **chore**: Other changes that don't modify src or test files
+- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+- **docs**: Documentation only changes
+- **feat**: A new feature
+- **fix**: A bug fix
+- **perf**: A code change that improves performance
+- **refactor**: A code change that neither fixes a bug nor adds a feature
+- **revert**: Reverts a previous commit
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- **test**: Adding missing tests or correcting existing tests
 
 #### Commit Scope
 
 The scope should be the name of the npm package affected, as perceived by the person reading the changelog.
 
 There are currently a few exceptions to the "use package name" rule:
 
--   **packaging**: used for changes that change the npm package layout in all of our packages, e.g. public path changes, package.json changes done to all packages, d.ts file/format changes, changes to bundles, etc.
--   **changelog**: used for updating the release notes in CHANGELOG.md
--   **lwc docs**: used for docs related changes within the lwc/docs directory of the repo
--   none/empty string: useful for `style`, `test` and `refactor` changes that are done across all packages (e.g. `style: add missing semicolons`)
+- **packaging**: used for changes that change the npm package layout in all of our packages, e.g. public path changes, package.json changes done to all packages, d.ts file/format changes, changes to bundles, etc.
+- **changelog**: used for updating the release notes in CHANGELOG.md
+- **lwc docs**: used for docs related changes within the lwc/docs directory of the repo
+- none/empty string: useful for `style`, `test` and `refactor` changes that are done across all packages (e.g. `style: add missing semicolons`)
 
 #### Commit Subject
 
 The subject contains a succinct description of the change:
 
--   use the imperative, present tense: "change" not "changed" nor "changes"
--   don't capitalize first letter
--   no dot (.) at the end
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize first letter
+- no dot (.) at the end
 
 #### Commit Body
 
@@ -350,17 +350,17 @@ The footer should contain any information about **Breaking Changes** and is also
 
 **Potential pitfalls:** When submitting changes to the LWC framework, there are several important considerations to keep in mind to ensure that your changes are reviewed & accepted.
 
--   The LWC framework makes strong guarantees about backwards compatibility to those that use our framework. Any changes that compromise these guarantees are unlikely to be accepted as-is.
--   If your change causes a test to fail in unit or integration tests, it is unlikely that your submission will be accepted as-is.
--   Certain parts of the codebase are particularly susceptible to breaking changes. This includes the browser runtime (`engine-core` and `engine-dom`), as well as the compiler (`compiler`, `style-compiler`, `template-compiler`).
--   Some areas of the codebase are less mature and undergoing active development. Areas related to SSR, including the server-side runtime (`engine-server`), fall under this category.
+- The LWC framework makes strong guarantees about backwards compatibility to those that use our framework. Any changes that compromise these guarantees are unlikely to be accepted as-is.
+- If your change causes a test to fail in unit or integration tests, it is unlikely that your submission will be accepted as-is.
+- Certain parts of the codebase are particularly susceptible to breaking changes. This includes the browser runtime (`engine-core` and `engine-dom`), as well as the compiler (`compiler`, `style-compiler`, `template-compiler`).
+- Some areas of the codebase are less mature and undergoing active development. Areas related to SSR, including the server-side runtime (`engine-server`), fall under this category.
 
 **Definition of done:** Especially when making large changes to the codebase, certain complementary work must be undertaken for the desired changes to be considered. When making a submission please adhere to the following:
 
--   All pre-existing unit- & integration- tests must pass.
--   If you modify a pre-existing test to accommodate your changes, a thorough reasoning must be proactively provided in the PR.
--   Test coverage should not decline – if you add code paths, add corresponding tests.
--   If your tests have the potential to negatively impact performance, provide a before & after comparison of performance using the test collateral provided in the repo.
+- All pre-existing unit- & integration- tests must pass.
+- If you modify a pre-existing test to accommodate your changes, a thorough reasoning must be proactively provided in the PR.
+- Test coverage should not decline – if you add code paths, add corresponding tests.
+- If your tests have the potential to negatively impact performance, provide a before & after comparison of performance using the test collateral provided in the repo.
 
 It's also worth noting that not all submissions will be accepted, even if all the above criteria are met. There may be constraints in the larger Salesforce ecosystem that prevent certain changes. If your submission is likely to change large parts of the codebase, please open an issue preemptively so that the design can be discussed.
 
 
@@ -34,10 +34,10 @@
     },
     "devDependencies": {
         "@commitlint/cli": "^19.6.0",
-        "@eslint/js": "9.15.0",
+        "@eslint/js": "9.16.0",
         "@lwc/eslint-plugin-lwc-internal": "link:./scripts/eslint-plugin",
         "@lwc/test-utils-lwc-internals": "link:./scripts/test-utils",
-        "@nx/js": "20.1.3",
+        "@nx/js": "20.1.4",
         "@rollup/plugin-commonjs": "^28.0.1",
         "@rollup/plugin-inject": "^5.0.5",
         "@rollup/plugin-node-resolve": "^15.3.0",
@@ -47,31 +47,31 @@
         "@swc/core": "~1.9.3",
         "@swc/helpers": "~0.5.15",
         "@types/babel__core": "^7.20.5",
-        "@types/node": "^22.9.3",
-        "@vitest/coverage-v8": "^2.1.5",
-        "@vitest/eslint-plugin": "^1.1.10",
-        "@vitest/ui": "^2.1.5",
+        "@types/node": "^22.10.1",
+        "@vitest/coverage-v8": "^2.1.7",
+        "@vitest/eslint-plugin": "^1.1.14",
+        "@vitest/ui": "^2.1.7",
         "bytes": "^3.1.2",
         "es-module-lexer": "^1.5.4",
-        "eslint": "9.15.0",
+        "eslint": "9.16.0",
         "eslint-config-flat-gitignore": "^0.3.0",
         "eslint-plugin-header": "^3.1.1",
         "eslint-plugin-import": "^2.31.0",
         "glob": "^11.0.0",
-        "globals": "^15.12.0",
+        "globals": "^15.13.0",
         "husky": "^9.1.7",
         "isbinaryfile": "^5.0.4",
         "jsdom": "^25.0.1",
         "lint-staged": "^15.2.10",
-        "magic-string": "^0.30.13",
-        "nx": "20.1.3",
-        "prettier": "^3.3.3",
-        "rollup": "^4.27.4",
+        "magic-string": "^0.30.14",
+        "nx": "20.1.4",
+        "prettier": "^3.4.1",
+        "rollup": "^4.28.0",
         "terser": "^5.36.0",
         "tslib": "^2.8.1",
         "typescript": "5.4.5",
-        "typescript-eslint": "8.15.0",
-        "vitest": "^2.1.5"
+        "typescript-eslint": "8.16.0",
+        "vitest": "^2.1.7"
     },
     "lint-staged": {
         "*.{js,mjs,ts}": "eslint",
 
@@ -4,15 +4,15 @@
 
 This babel plugin does the following transform:
 
--   Global decorator transform:
-    -   Transform `@api` decorator to `publicProperties` and `publicMethods` static properties.
-    -   Transform `@wire` decorator to `wire` static property.
-    -   Transform `@track` decorator to `track` static property.
--   LWC component class sugar syntax:
-    -   Check for misspelled lifecycle hooks.
-    -   Import and inject `render` from a collocated template if a component class doesn't already implement a `render` method.
--   Optimization:
-    -   If the compiler inject the default template a component, it will also wire the template style to the component.
+- Global decorator transform:
+    - Transform `@api` decorator to `publicProperties` and `publicMethods` static properties.
+    - Transform `@wire` decorator to `wire` static property.
+    - Transform `@track` decorator to `track` static property.
+- LWC component class sugar syntax:
+    - Check for misspelled lifecycle hooks.
+    - Import and inject `render` from a collocated template if a component class doesn't already implement a `render` method.
+- Optimization:
+    - If the compiler inject the default template a component, it will also wire the template style to the component.
 
 ## Installation
 
@@ -42,11 +42,11 @@ const { code } = babel.transformSync(source, {
 
 ## Options
 
--   `name` (type: `string`, optional) - name of the component, e.g. `foo` in `x/foo`.
--   `namespace` (type: `string`, optional) - namepace of the component, e.g. `x` in `x/foo`.
--   `isExplicitImport` (type: `boolean`, optional) - true if this is an explicit import.
--   `dynamicImports` (type: `object`, optional) - see below:
-    -   `loader` (type: `string`, optional) - loader to use at runtime.
-    -   `strictSpecifier` (type: `boolean`, optional) - true if a strict specifier should be used.
--   `instrumentation` (type: `InstrumentationObject`, optional) - instrumentation object to gather metrics and non-error logs for internal use. See the `@lwc/errors` package for details on the interface.
--   `apiVersion` (type: `number`, optional) - API version to associate with the compiled component.
+- `name` (type: `string`, optional) - name of the component, e.g. `foo` in `x/foo`.
+- `namespace` (type: `string`, optional) - namepace of the component, e.g. `x` in `x/foo`.
+- `isExplicitImport` (type: `boolean`, optional) - true if this is an explicit import.
+- `dynamicImports` (type: `object`, optional) - see below:
+    - `loader` (type: `string`, optional) - loader to use at runtime.
+    - `strictSpecifier` (type: `boolean`, optional) - true if a strict specifier should be used.
+- `instrumentation` (type: `InstrumentationObject`, optional) - instrumentation object to gather metrics and non-error logs for internal use. See the `@lwc/errors` package for details on the interface.
+- `apiVersion` (type: `number`, optional) - API version to associate with the compiled component.