Skip to content

Pin font icons versions to latest#464

Merged
sronveaux merged 2 commits into
wegue-oss:masterfrom
sronveaux:update-md-mdi
Dec 15, 2025
Merged

Pin font icons versions to latest#464
sronveaux merged 2 commits into
wegue-oss:masterfrom
sronveaux:update-md-mdi

Conversation

@sronveaux
Copy link
Copy Markdown
Collaborator

This small PR pins the Material Design Icons and material-icons to latest available versions.
This is part of the must-have points to address before Wegue v3 is out and is thus mentioned in the upgrade notes.

The PR does nothing in practice, as the versions present inside the package.json file were:

  • "@mdi/font": "^7.2.96"
  • "material-icons": "^1.13.9"

As latest versions are 7.4.47 for MDI and 1.13.14 for material-icons and as dependencies were pinned with a ^, someone who had installed dependencies lately was already fetching those latest versions.
However, as discussed in #319 some times ago, changing version of those icon fonts can bring bad surprises as some icons are removed or replaced from version to version. In our case, no icon disappeared but some were updated and so can have a different visual even between minor version updates. That's why I propose to pin those fonts to the exact version as is already the case for OpenLayers and Proj4.

I also propose to move them from the devDependencies to the dependencies section as they are clearly part of the assets distributed at runtime and are not dev-only. In practice, as we're using Vite, the change has no impact, it is purely philosophical and merely clarifies the use that is made of these packages.

@fschmenger
Copy link
Copy Markdown
Collaborator

Hi @sronveaux,
I'm short on time but can you check which recent version upgrade of @mdi/font or material-icons introduced into Wegue had breaking changes?
In theory pinning down to an exact version shouldn't be necessary, as long as the respective packages do semantic versioning properly. If they really screwed it up within the same minor version, should we consider using the ~version “Approximately equivalent to version” operator instead?

@chrismayer
Copy link
Copy Markdown
Collaborator

Totally agree that these are no devDependecies.

Regarding pinpointing: If we can assure that semantic versioning is used by these 2 packages we could use ~ or ^, otherwise I am also fine with pinning them.

@chrismayer
Copy link
Copy Markdown
Collaborator

chrismayer commented Dec 9, 2025

I just read again carefully the description of @sronveaux and this

However, as discussed in #319 some times ago, changing version of those icon fonts can bring bad surprises as some icons are removed or replaced from version to version. In our case, no icon disappeared but some were updated and so can have a different visual even between minor version updates.

makes me +1 for pinpointing the versions. I also checked the repos of @mdi/font and material-icons and they are quite intransparent, what changed and what is part of the releases, which also makes me feel pinpointing could be a good idea.

@sronveaux
Copy link
Copy Markdown
Collaborator Author

Hi @fschmenger and @chrismayer and thanks for your returns,

I totally agree that using the minor version ^ when possible and using the patch ~ otherwise is the rule to follow as much as possible.

What makes me change my mind for those icon fonts is exactly the lack of traceability between versions.
Just to give some more information about what can be found:

  • Concerning Material Design Icons, there is a changelog that can be viewed here in which we can see what can be assimilated as breaking changes, going back from the latest major version update:
    • V7.0.96: latest major release
    • V7.1.96: 31 updated icons and 3 renamed icons
    • V7.2.96: 1 renamed icon
    • V7.3.67: 9 updated icons
    • V7.4.47: 4 updated icons
  • Concerning material-icons, we cannot find any changelog and have to delve ourselves in the repository to see what happens. The only thing we can see is the icon version numbers pinned in a json file. Just to give some examples:
    • V1.13.9: Taken as reference
    • V1.13.10: 5 updated icon versions
    • V1.13.11: 6 updated icon versions
    • V1.13.12: 1 updated icon version
    • V1.13.13: 1 updated icon version
    • V1.13.14: 1 updated icon version

So now all depends what we call a breaking change. Except that MDI has two real breaking changes listed here where some icons have been renamed, the rest is conform to semver in a sense, they patch icons, so it is not a breaking change, your app will still function properly if the fonts are updated, but there is a risk that the visual changes somehow. It would be a pity that the updated icons are the ones you use for sure but this could happen. login and logout were modified in MDI@7.3.67 for example.

As for using the ~ instead of pinning exact versions, with material-icons we can see that the problem would persist and concerning MDI, if they follow their current logic, you only get a single patch version per minor version so this would change nothing in itself but I preferred to uniformize the way icon fonts are managed and be careful... even though in the end, those icon fonts should not be updated that much in the future...

Just tell me what you think about this and I'll adapt as necessary!

Cheers,
Sébastien

Copy link
Copy Markdown
Collaborator

@fschmenger fschmenger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, +1 for pinning then, thanks for the detailed explanantion!
Feel free to merge.

@sronveaux sronveaux merged commit f0f8426 into wegue-oss:master Dec 15, 2025
1 check passed
@sronveaux sronveaux deleted the update-md-mdi branch December 15, 2025 20:31
@sronveaux sronveaux added dependencies Pull requests that update a dependency file Wegue v3 labels Jan 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file Wegue v3

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants