Skip to content

⬆️ Update dependency @wuchale/vite-plugin to ^0.15.2 - autoclosed - #831

Closed
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/wuchale-vite-plugin-0.x
Closed

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/wuchale-vite-plugin-0.x

Conversation

@renovate

@renovate renovate Bot commented Nov 3, 2025

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
@wuchale/vite-plugin (source) ^0.14.8 -> ^0.15.2 age confidence

Release Notes

wuchalejs/wuchale (@​wuchale/vite-plugin)

v0.15.2

Compare Source

Patch Changes
  • 12d17f7: Fix inconsistent wuchale versions

v0.15.1

Compare Source

Patch Changes
  • 3d451d3: Update after fix compiled catalogs writing

v0.15.0

Compare Source

Minor Changes
  • 37deb80: Always use physical files, change catalog config to localesDir

    Previusly virtual modules offered by Vite made it possible to keep the file system
    clean and a slight performance advantage when building, but they had disadvantages:

    • Inspecting what Wuchale generates was not possible unless the writeFiles config was enabled
    • They don't work outside of Vite
    • Supporting physical files was therefore unavoidable and that meant supporting two different systems to export the same things

    Now everything is written to disk, including proxies, compiled catalogs, and
    locales data too. And writeFiles has been removed. In cases where writing the
    transformed code is desired, the destination can be provided to the outDir adapter
    config.

    The second thing is that the location of the catalog files was previusly
    specified using the catalog adapter config, which accepted a substitution
    parameter, {locale} but it's an unnecessary complexity that can lead to
    problems, and it's not just catalogs that's stored in that location. Therefore,
    it has been replaced by the self descriptive config, localesDir.

Patch Changes

Configuration

📅 Schedule: Branch creation - Between 12:00 AM and 04:59 PM, only on Monday ( * 0-16 * * 1 ) (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot had a problem deploying to #831: App preview November 3, 2025 08:56 Failure
@renovate renovate Bot changed the title ⬆️ Update dependency @wuchale/vite-plugin to ^0.15.2 ⬆️ Update dependency @wuchale/vite-plugin to ^0.15.2 - autoclosed Nov 3, 2025
@renovate renovate Bot closed this Nov 3, 2025
@renovate
renovate Bot deleted the renovate/wuchale-vite-plugin-0.x branch November 3, 2025 09:43
gwennlbh pushed a commit that referenced this pull request Aug 3, 2026
##### [v7.5.0](https://github.com/krisk/Fuse/blob/HEAD/CHANGELOG.md#750-2026-07-13)

##### ⚠️ Behavior changes

Every change in this release is a bug fix, but each one corrects a **scoring or ranking** bug. Scores and result ordering will shift for some queries. That is why this ships as a minor rather than a patch: the public API is unchanged and upgrading is a drop-in, but the results you get back can differ, and that should not arrive silently in a patch bump.

If you assert on exact `score` values or on a specific result order, expect those assertions to need updating. Re-baseline them against 7.5.0 rather than pinning to 7.4.x, since the 7.4.x behavior was wrong in the cases below.

- **Field-length normalisation now counts words correctly.** Tabs and newlines were not treated as word separators, so a multi-line or tab-delimited field was scored as though it were one long word, making it look far shorter than it is. Fields containing `\t`, `\n`, or `\r` now score differently ([#830](krisk/Fuse#830)).
- **Key weights are now normalised in object and keyless-logical search.** Weights that did not sum to `1` were applied unnormalised, skewing the relative influence of each key. If your `keys` weights do not already sum to `1`, your relative ranking changes ([#833](krisk/Fuse#833)).
- **`limit` now returns the correct top-N when scores tie.** A tie at the cutoff boundary could evict a result that should have been kept, so `limit` could return the *wrong* items, not merely the right items in a different order ([#835](krisk/Fuse#835)).
- **Bitap respects `minMatchCharLength` in the exact-match shortcut.** Matches shorter than `minMatchCharLength` were still reported via the exact-match fast path, so the `matches` array could contain entries it was configured to exclude ([#831](krisk/Fuse#831)).

##### Bug Fixes

- **bitap:** respect minMatchCharLength in exact-match shortcut ([dbb98b6](krisk/Fuse@dbb98b6)), closes [#831](krisk/Fuse#831)
- **fieldNorm:** count tabs and newlines as word separators ([6fe85b0](krisk/Fuse@6fe85b0)), closes [#830](krisk/Fuse#830)
- **fieldNorm:** count word-starts instead of space transitions ([2946f97](krisk/Fuse@2946f97))
- **scoring:** normalise key weights in object and keyless-logical search ([e164b61](krisk/Fuse@e164b61)), closes [#833](krisk/Fuse#833)
- **search:** keep the correct top-N under limit when scores tie ([437f8f3](krisk/Fuse@437f8f3)), closes [#835](krisk/Fuse#835), thanks [@spokodev](https://github.com/spokodev) for the report and the fix

##### [7.4.2](krisk/Fuse@v7.4.1...v7.4.2) (2026-06-05)

##### Bug Fixes

- **types:** emit CommonJS declarations (.d.cts) for node16/nodenext ([#780](krisk/Fuse#780)) ([33f5d29](krisk/Fuse@33f5d29))

##### [7.4.1](krisk/Fuse@v7.4.0...v7.4.1) (2026-06-02)

##### Bug Fixes

- **types:** add TypeScript declarations for fuse.js/worker-script ([6ef6c33](krisk/Fuse@6ef6c33)), closes [#828](krisk/Fuse#828)
- **types:** ship TypeScript declarations for fuse.js/worker ([572ad1e](krisk/Fuse@572ad1e)), closes [#828](krisk/Fuse#828)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

This branch had an error being deployed

1 failed and 3 active deployments
#831: App preview — 8b189b69 Deployed Nov 3, 2025 by renovate[bot]
#831: Test coverage report — 8b189b69 Deployed Nov 3, 2025 by renovate[bot]
#831: End-to-end tests report — 8b189b69 Deployed Nov 3, 2025 by renovate[bot]
#831: Unit tests report — 8b189b69 Deployed Nov 3, 2025 by renovate[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants