Bump the npm-dependencies group across 1 directory with 2 updates

[dependabot]

Bumps the npm-dependencies group with 2 updates in the /components/dash-html-components directory: @types/node and webpack-sources.

Updates @types/node from 26.6.2 to 26.6.5

Commits

• See full diff in compare view

Updates webpack-sources from 3.5.1 to 3.6.0

Release notes

Sourced from webpack-sources's releases.

v3.6.0

Minor Changes

• Add map({ scopes: true }), emitting the source map scopes field from the bindings a source declares. (by @​alexander-akait in #275)

Patch Changes

• Create a cached source's map cache only once a map is asked for. (by @​alexander-akait in #296)

v3.5.3

Patch Changes

• Hand out a recorded hash update as buffers, so cached data carries no big string. (by @​alexander-akait in #289)

v3.5.2

Patch Changes

• perf: hash a string-backed source without materializing its buffer (by @​alexander-akait in #286)

  RawSource.updateHash and OriginalSource.updateHash called buffer(), which encodes the string to UTF-8 and memoizes the result — so every source that was hashed kept its content twice, as a string and as a buffer, for as long as the source lived. Node hashes a string as UTF-8, the same bytes buffer() produces, so the string is hashed directly instead and no digest changes.

  Measured on a webpack build of three.js + lodash-es (1033 modules, 2.71 MB of module source): retained arrayBuffers after the build drop from 8.74–8.76 MB to 5.81 MB with devtool: false, and from 9.35–12.11 MB to 6.42 MB with devtool: "source-map" — disjoint over six and five runs. 1029 Buffer.from calls per build are removed, one per module. CPU is unchanged: hashing those sources costs 9.23 ms via the buffer against 8.18 ms via the string, which no whole-build timing can resolve.

Changelog

Sourced from webpack-sources's changelog.

3.6.0

Minor Changes

• Add map({ scopes: true }), emitting the source map scopes field from the bindings a source declares. (by @​alexander-akait in #275)

Patch Changes

• Create a cached source's map cache only once a map is asked for. (by @​alexander-akait in #296)

3.5.3

Patch Changes

• Hand out a recorded hash update as buffers, so cached data carries no big string. (by @​alexander-akait in #289)

3.5.2

Patch Changes

• perf: hash a string-backed source without materializing its buffer (by @​alexander-akait in #286)

  RawSource.updateHash and OriginalSource.updateHash called buffer(), which encodes the string to UTF-8 and memoizes the result — so every source that was hashed kept its content twice, as a string and as a buffer, for as long as the source lived. Node hashes a string as UTF-8, the same bytes buffer() produces, so the string is hashed directly instead and no digest changes.

  Measured on a webpack build of three.js + lodash-es (1033 modules, 2.71 MB of module source): retained arrayBuffers after the build drop from 8.74–8.76 MB to 5.81 MB with devtool: false, and from 9.35–12.11 MB to 6.42 MB with devtool: "source-map" — disjoint over six and five runs. 1029 Buffer.from calls per build are removed, one per module. CPU is unchanged: hashing those sources costs 9.23 ms via the buffer against 8.18 ms via the string, which no whole-build timing can resolve.

Commits

• 4f49c30 ci: make the CodSpeed memory benchmarks deterministic (#298)
• 50fc1db chore(release): new release (#295)
• d3548f7 test: check every mapping the library writes (#297)
• f2bfd3a perf: create a cached source's map cache on first use (#296)
• 5a9b34d fix: keep scope bindings through CachedSource replays and cached data (#293)
• 2bd50f3 feat: emit the source map scopes field (#275)
• 82a4bf0 test: run tests with node:test, keep Jest for old Node.js versions (#292)
• fba8312 chore: generate types with the TypeScript CLI instead of tooling (#291)
• 05f71a8 chore(release): new release (#290)
• 1c97070 fix: hand out a recorded hash update as buffers (#289)
• Additional commits viewable in compare view

[github-actions]

Dash performance benchmarks

❌ perf regression

	scenario	metric	p90 (ms)	median	growth	baseline p90	note
❌	full_children_replace	replace_ms	7034.2	1614.8	29.91x	4697.1	p90 7034.2ms > warn 6000ms; 2.0x baseline (norm)
✅	callback_chain	chain_ms	339.3	320.9	0.91x	499.1
✅	callback_chain	graph_ms	2.3	2.3	1.0x	2.4
✅	callback_fanout	fanout_ms	76.5	68.9	0.86x	92.5
✅	deep_nesting	render_ms	44.3	43.4	1.25x	56.8
✅	initial_render_large	render_ms	509.2	458.0	0.89x	694.4
✅	initial_render_small	render_ms	80.7	71.3	0.98x	104.0
✅	patch_append_nested	append_ms	154.7	106.2	2.6x	192.3
✅	patch_append_toplevel	append_ms	130.4	90.8	2.62x	140.2
✅	patch_scalar_update_large	update_ms	170.5	154.0	0.9x	202.9
✅	wildcard_all_resolve	wildcard_ms	239.5	223.1	0.92x	313.6
✅	wildcard_all_resolve	graph_ms	0.9	0.9	1.0x	1.3

growth = late-third / early-third per-op time; ~1 is flat, a large value means the per-op cost scales with accumulated state.

machine scale vs baseline: 0.74x - divided out of the baseline ratios so they compare like for like (the absolute warn/fail ceilings are left un-scaled); calibrated on initial_render_small.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud