sfdx-lwc-jest icon indicating copy to clipboard operation
sfdx-lwc-jest copied to clipboard

Published 20 hours ago • verified publisher icon salesforce

chore: bump the theoretically-non-breaking group across 1 directory with 9 updates

Open dependabot[bot] opened this issue 6 months ago • 0 comments

Bumps the theoretically-non-breaking group with 9 updates in the / directory:

Package From To
@lwc/compiler 8.16.4 8.19.1
@lwc/engine-dom 8.16.4 8.19.1
@lwc/engine-server 8.16.4 8.19.1
@lwc/module-resolver 8.16.4 8.19.1
@lwc/synthetic-shadow 8.16.4 8.19.1
@lwc/wire-service 8.16.4 8.19.1
@babel/core 7.26.10 7.27.4
@babel/eslint-parser 7.27.0 7.27.1
@babel/plugin-proposal-decorators 7.25.9 7.27.1

Updates @lwc/compiler from 8.16.4 to 8.19.1

Release notes

Sourced from @​lwc/compiler's releases.

v8.19.1

What's Changed

v8.19.0

Better types for template elements

TypeScript component authors can now specify a new property, __lwc_public_property_types__, to indicate to TypeScript which properties are available on the element created by a component. This prevents erroneous property definitions, which are otherwise unavoidable due to the way that TypeScript implements decorators.

Example

// <c-inferred-props>
class InferredProps extends LightningElement {
  @api exposed = 'hello'
  internal = 'secret'
}

// <c-explicit-props>

class ExplicitProps extends InferredProps {

lwc_public_property_types?: {

exposed: string

}

}


class Container extends LightningElement {

checkInferred() {

const inferred = this.querySelector<LightningHTMLElement<InferredProps>>('c-inferred-props')!

inferred.exposed // ✅ Valid, no type error

inferred.internal // ❌ Invalid, but no type error!

}


checkExplicit() {

const explicit = this.querySelector<LightningHTMLElement<ExplicitProps>>('c-explicit-props')!

explicit.exposed // ✅ Valid, no type error

explicit.internal // ✅ Invalid, and a type error occurs!

}

}

In this example, the element interface for c-inferred-props is defined by LightningHTMLElement<InferredProps>. That interface has an erroneous property definition, internal. The internal property is part of the component interface, but is not decorated with @api, so it should not be part of the element interface.

The element interface for c-explicit-props is defined by LightningHTMLElement<ExplicitProps>. Because ExplicitProps defines __lwc_public_property_types__, the element interface does not include the internal property, which is the correct behavior.

What else changed?

... (truncated)

Commits

Updates @lwc/engine-dom from 8.16.4 to 8.19.1

Release notes

Sourced from @​lwc/engine-dom's releases.

v8.19.1

What's Changed

v8.19.0

Better types for template elements

TypeScript component authors can now specify a new property, __lwc_public_property_types__, to indicate to TypeScript which properties are available on the element created by a component. This prevents erroneous property definitions, which are otherwise unavoidable due to the way that TypeScript implements decorators.

Example

// <c-inferred-props>
class InferredProps extends LightningElement {
  @api exposed = 'hello'
  internal = 'secret'
}

// <c-explicit-props>

class ExplicitProps extends InferredProps {

lwc_public_property_types?: {

exposed: string

}

}


class Container extends LightningElement {

checkInferred() {

const inferred = this.querySelector<LightningHTMLElement<InferredProps>>('c-inferred-props')!

inferred.exposed // ✅ Valid, no type error

inferred.internal // ❌ Invalid, but no type error!

}


checkExplicit() {

const explicit = this.querySelector<LightningHTMLElement<ExplicitProps>>('c-explicit-props')!

explicit.exposed // ✅ Valid, no type error

explicit.internal // ✅ Invalid, and a type error occurs!

}

}

In this example, the element interface for c-inferred-props is defined by LightningHTMLElement<InferredProps>. That interface has an erroneous property definition, internal. The internal property is part of the component interface, but is not decorated with @api, so it should not be part of the element interface.

The element interface for c-explicit-props is defined by LightningHTMLElement<ExplicitProps>. Because ExplicitProps defines __lwc_public_property_types__, the element interface does not include the internal property, which is the correct behavior.

What else changed?

... (truncated)

Commits

Updates @lwc/engine-server from 8.16.4 to 8.19.1

Release notes

Sourced from @​lwc/engine-server's releases.

v8.19.1

What's Changed

v8.19.0

Better types for template elements

TypeScript component authors can now specify a new property, __lwc_public_property_types__, to indicate to TypeScript which properties are available on the element created by a component. This prevents erroneous property definitions, which are otherwise unavoidable due to the way that TypeScript implements decorators.

Example

// <c-inferred-props>
class InferredProps extends LightningElement {
  @api exposed = 'hello'
  internal = 'secret'
}

// <c-explicit-props>

class ExplicitProps extends InferredProps {

lwc_public_property_types?: {

exposed: string

}

}


class Container extends LightningElement {

checkInferred() {

const inferred = this.querySelector<LightningHTMLElement<InferredProps>>('c-inferred-props')!

inferred.exposed // ✅ Valid, no type error

inferred.internal // ❌ Invalid, but no type error!

}


checkExplicit() {

const explicit = this.querySelector<LightningHTMLElement<ExplicitProps>>('c-explicit-props')!

explicit.exposed // ✅ Valid, no type error

explicit.internal // ✅ Invalid, and a type error occurs!

}

}

In this example, the element interface for c-inferred-props is defined by LightningHTMLElement<InferredProps>. That interface has an erroneous property definition, internal. The internal property is part of the component interface, but is not decorated with @api, so it should not be part of the element interface.

The element interface for c-explicit-props is defined by LightningHTMLElement<ExplicitProps>. Because ExplicitProps defines __lwc_public_property_types__, the element interface does not include the internal property, which is the correct behavior.

What else changed?

... (truncated)

Commits

Updates @lwc/module-resolver from 8.16.4 to 8.19.1

Release notes

Sourced from @​lwc/module-resolver's releases.

v8.19.1

What's Changed

v8.19.0

Better types for template elements

TypeScript component authors can now specify a new property, __lwc_public_property_types__, to indicate to TypeScript which properties are available on the element created by a component. This prevents erroneous property definitions, which are otherwise unavoidable due to the way that TypeScript implements decorators.

Example

// <c-inferred-props>
class InferredProps extends LightningElement {
  @api exposed = 'hello'
  internal = 'secret'
}

// <c-explicit-props>

class ExplicitProps extends InferredProps {

lwc_public_property_types?: {

exposed: string

}

}


class Container extends LightningElement {

checkInferred() {

const inferred = this.querySelector<LightningHTMLElement<InferredProps>>('c-inferred-props')!

inferred.exposed // ✅ Valid, no type error

inferred.internal // ❌ Invalid, but no type error!

}


checkExplicit() {

const explicit = this.querySelector<LightningHTMLElement<ExplicitProps>>('c-explicit-props')!

explicit.exposed // ✅ Valid, no type error

explicit.internal // ✅ Invalid, and a type error occurs!

}

}

In this example, the element interface for c-inferred-props is defined by LightningHTMLElement<InferredProps>. That interface has an erroneous property definition, internal. The internal property is part of the component interface, but is not decorated with @api, so it should not be part of the element interface.

The element interface for c-explicit-props is defined by LightningHTMLElement<ExplicitProps>. Because ExplicitProps defines __lwc_public_property_types__, the element interface does not include the internal property, which is the correct behavior.

What else changed?

... (truncated)

Commits

Updates @lwc/synthetic-shadow from 8.16.4 to 8.19.1

Release notes

Sourced from @​lwc/synthetic-shadow's releases.

v8.19.1

What's Changed

v8.19.0

Better types for template elements

TypeScript component authors can now specify a new property, __lwc_public_property_types__, to indicate to TypeScript which properties are available on the element created by a component. This prevents erroneous property definitions, which are otherwise unavoidable due to the way that TypeScript implements decorators.

Example

// <c-inferred-props>
class InferredProps extends LightningElement {
  @api exposed = 'hello'
  internal = 'secret'
}

// <c-explicit-props>

class ExplicitProps extends InferredProps {

lwc_public_property_types?: {

exposed: string

}

}


class Container extends LightningElement {

checkInferred() {

const inferred = this.querySelector<LightningHTMLElement<InferredProps>>('c-inferred-props')!

inferred.exposed // ✅ Valid, no type error

inferred.internal // ❌ Invalid, but no type error!

}


checkExplicit() {

const explicit = this.querySelector<LightningHTMLElement<ExplicitProps>>('c-explicit-props')!

explicit.exposed // ✅ Valid, no type error

explicit.internal // ✅ Invalid, and a type error occurs!

}

}

In this example, the element interface for c-inferred-props is defined by LightningHTMLElement<InferredProps>. That interface has an erroneous property definition, internal. The internal property is part of the component interface, but is not decorated with @api, so it should not be part of the element interface.

The element interface for c-explicit-props is defined by LightningHTMLElement<ExplicitProps>. Because ExplicitProps defines __lwc_public_property_types__, the element interface does not include the internal property, which is the correct behavior.

What else changed?

... (truncated)

Commits

Updates @lwc/wire-service from 8.16.4 to 8.19.1

Release notes

Sourced from @​lwc/wire-service's releases.

v8.19.1

What's Changed

v8.19.0

Better types for template elements

TypeScript component authors can now specify a new property, __lwc_public_property_types__, to indicate to TypeScript which properties are available on the element created by a component. This prevents erroneous property definitions, which are otherwise unavoidable due to the way that TypeScript implements decorators.

Example

// <c-inferred-props>
class InferredProps extends LightningElement {
  @api exposed = 'hello'
  internal = 'secret'
}

// <c-explicit-props>

class ExplicitProps extends InferredProps {

lwc_public_property_types?: {

exposed: string

}

}


class Container extends LightningElement {

checkInferred() {

const inferred = this.querySelector<LightningHTMLElement<InferredProps>>('c-inferred-props')!

inferred.exposed // ✅ Valid, no type error

inferred.internal // ❌ Invalid, but no type error!

}


checkExplicit() {

const explicit = this.querySelector<LightningHTMLElement<ExplicitProps>>('c-explicit-props')!

explicit.exposed // ✅ Valid, no type error

explicit.internal // ✅ Invalid, and a type error occurs!

}

}

In this example, the element interface for c-inferred-props is defined by LightningHTMLElement<InferredProps>. That interface has an erroneous property definition, internal. The internal property is part of the component interface, but is not decorated with @api, so it should not be part of the element interface.

The element interface for c-explicit-props is defined by LightningHTMLElement<ExplicitProps>. Because ExplicitProps defines __lwc_public_property_types__, the element interface does not include the internal property, which is the correct behavior.

What else changed?

... (truncated)

Commits

Updates @babel/core from 7.26.10 to 7.27.4

Release notes

Sourced from @​babel/core's releases.

v7.27.4 (2025-05-30)

:eyeglasses: Spec Compliance

  • babel-parser, babel-plugin-proposal-explicit-resource-management

:nail_care: Polish

:microscope: Output optimization

  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-async-to-generator, babel-plugin-transform-block-scoping, babel-plugin-transform-classes, babel-plugin-transform-destructuring, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs2, babel-runtime-corejs3, babel-runtime
  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-async-to-generator, babel-plugin-transform-block-scoping, babel-plugin-transform-classes, babel-plugin-transform-destructuring, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs3
  • babel-core, babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-async-to-generator, babel-plugin-transform-block-scoping, babel-plugin-transform-classes, babel-plugin-transform-destructuring, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs2, babel-runtime-corejs3, babel-runtime, babel-standalone

Committers: 4

v7.27.3 (2025-05-27)

:bug: Bug Fix

  • babel-generator
  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-regenerator, babel-preset-env, babel-runtime-corejs3
  • babel-plugin-proposal-explicit-resource-management
  • babel-plugin-proposal-decorators, babel-types
    • #17321 fix(converter): Remove abstract modifiers in class declaration to expression conversion (@​magic-akari)
  • babel-helper-module-transforms, babel-plugin-proposal-explicit-resource-management, babel-plugin-transform-modules-amd, babel-plugin-transform-modules-commonjs, babel-plugin-transform-modules-umd
    • #17257 Preserve class id when transforming using declarations with exported class (@​JLHwung)
  • babel-parser
  • babel-generator, babel-parser

Committers: 7

... (truncated)

Changelog

Sourced from @​babel/core's changelog.

v7.27.4 (2025-05-30)

:eyeglasses: Spec Compliance

  • babel-parser, babel-plugin-proposal-explicit-resource-management

:nail_care: Polish

:microscope: Output optimization

  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-async-to-generator, babel-plugin-transform-block-scoping, babel-plugin-transform-classes, babel-plugin-transform-destructuring, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs2, babel-runtime-corejs3, babel-runtime
  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-async-to-generator, babel-plugin-transform-block-scoping, babel-plugin-transform-classes, babel-plugin-transform-destructuring, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs3
  • babel-core, babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-async-to-generator, babel-plugin-transform-block-scoping, babel-plugin-transform-classes, babel-plugin-transform-destructuring, babel-plugin-transform-regenerator, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs2, babel-runtime-corejs3, babel-runtime, babel-standalone

v7.27.3 (2025-05-27)

:bug: Bug Fix

  • babel-generator
  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-regenerator, babel-preset-env, babel-runtime-corejs3
  • babel-plugin-proposal-explicit-resource-management
  • babel-plugin-proposal-decorators, babel-types
    • #17321 fix(converter): Remove abstract modifiers in class declaration to expression conversion (@​magic-akari)
  • babel-helper-module-transforms, babel-plugin-proposal-explicit-resource-management, babel-plugin-transform-modules-amd, babel-plugin-transform-modules-commonjs, babel-plugin-transform-modules-umd
    • #17257 Preserve class id when transforming using declarations with exported class (@​JLHwung)
  • babel-parser
  • babel-generator, babel-parser

v7.27.2 (2025-05-06)

:bug: Bug Fix

  • babel-parser
  • babel-plugin-transform-object-rest-spread
  • babel-plugin-transform-modules-commonjs, babel-template

:running_woman: Performance

  • babel-cli

... (truncated)

Commits

Updates @babel/eslint-parser from 7.27.0 to 7.27.1

Release notes

Sourced from @​babel/eslint-parser's releases.

v7.27.1 (2025-04-30)

Thanks @​kermanx and @​woaitsAryan for your first PRs!

:eyeglasses: Spec Compliance

:bug: Bug Fix

  • babel-plugin-proposal-destructuring-private, babel-plugin-proposal-do-expressions, babel-traverse
  • babel-helper-wrap-function, babel-plugin-transform-async-to-generator
  • babel-helper-remap-async-to-generator, babel-plugin-transform-async-to-generator
  • babel-helper-fixtures, babel-parser
  • babel-generator, babel-parser
    • #17226 Fill optional AST properties when both estree and typescript parser plugin are enabled (Part 2) (@​JLHwung)
  • babel-parser
    • #17224 Fill optional AST properties when both estree and typescript parser plugin are enabled (Part 1) (@​JLHwung)
    • #17080 Fix start of TSParameterProperty (@​JLHwung)
  • babel-compat-data, babel-preset-env
  • babel-traverse
  • babel-generator

:nail_care: Polish

  • babel-plugin-bugfix-v8-spread-parameters-in-optional-chaining, babel-plugin-proposal-decorators, babel-plugin-transform-arrow-functions, babel-plugin-transform-class-properties, babel-plugin-transform-destructuring, babel-plugin-transform-object-rest-spread, babel-plugin-transform-optional-chaining, babel-plugin-transform-parameters, babel-traverse

:house: Internal

  • babel-runtime-corejs2, babel-runtime-corejs3, babel-runtime
  • babel-compat-data, babel-preset-env
  • babel-compat-data, babel-standalone
  • babel-register
  • babel-helpers, babel-plugin-transform-async-generator-functions, babel-plugin-transform-regenerator, babel-preset-env, babel-runtime-corejs3
  • All packages

... (truncated)

Changelog

Sourced from @​babel/eslint-parser's changelog.

v7.27.1 (2025-04-30)

:eyeglasses: Spec Compliance

:bug: Bug Fix

  • babel-plugin-proposal-destructuring-private, babel-plugin-proposal-do-expressions, babel-traverse
  • babel-helper-wrap-function, babel-plugin-transform-async-to-generator
  • babel-helper-remap-async-to-generator, babel-plugin-transform-async-to-generator
  • babel-helper-fixtures, babel-parser
  • babel-generator, babel-parser
    • #17226 Fill optional AST properties when both estree and typescript parser plugin are enabled (Part 2) (@​JLHwung)
  • babel-parser
    • #17224 Fill optional AST properties when both estree and typescript parser plugin are enabled (Part 1) (@​JLHwung)
    • #17080 Fix start of TSParameterProperty (@​JLHwung)
  • babel-compat-data, babel-preset-env
  • babel-traverse
  • babel-generator

:nail_care: Polish

  • babel-plugin-bugfix-v8-spread-parameters-in-optional-chaining, babel-plugin-proposal-decorators, babel-plugin-transform-arrow-functions, babel-plugin-transform-class-properties, babel-plugin-transform-destructuring, babel-plugin-transform-object-rest-spread, babel-plugin-transform-optional-chaining, babel-plugin-transform-parameters, babel-traverse

:house: Internal

  • babel-runtime-corejs2, babel-runtime-corejs3, babel-runtime
    • ...

      Description has been truncated

dependabot[bot] avatar Jun 01 '25 21:06 dependabot[bot]