Change:
}, { "component": { <ins> "type": "git", "git": { "name": "vscode-octicons-font", "repositoryUrl": "https://github.com/Microsoft/vscode-octicons-font", "commitHash": "174697a8d28a65dc6600c44d239bd75f7d157c71" } }, "license": "MIT", "version": "1.0.0" }, { "component": { </ins> "type": "npm", "npm": { "name": "mdn-data",

Discussion:
Related to This issue is to track the progress of updating our version of (3.1.0) to the latest version (8.2.0). We'll need to create the work to convert the latest versions (svg) back into an icon font. Below are the requirements for this work: [x] Convert svgs into icon font [x] Include backward compatibility [x] Map old unicodes to new icons [x] Remove unnecessary font files [x] Add/update proper licenses [x] Test new icon font Working branch can be found under . Below is a list of the new additions: - - - - - - - - - - Please refer to for a full list of updates. :octocat: :heart:
Is this also going to address ?
this is only for addressing Octicons, which are only used in the status bar. will be likely be address when we get to , which I'm hoping to start on this iteration.

Unfortunately not so easy because some octicons have been removed and hence updating might likely break some extensions that rely on them
Is there a plan going forwards with this? I just tried to use an octicon and it came up blank. I couldn't work out why until I checked the versions being used, which led me here. From the change log, it looks like some of the removed icons are just renamed. Would it be possible to add a simple 'redirect' to return the new icon if the old name is used? Similarly, if an icon has genuinely been removed, could a placeholder be returned? In fact, it would probably be nicer to return something if a bad icon is named, rather than leaving a blank space.
Hm... Do you have a pointer/release notes that describe these changes?
I was just looking through here:
Yeah, so I believe we would miss two icons and we might wanna risk that... For the other we have alternatives in place... No promises, stretch for June (also accepting PRs)
Great - thanks!
So, this would be the compat table and the good news is that no extension seems to use those three removed icons. The bad news is that octicons are now shipped as npm module which we cannot consume at the level at which we define the
we already have all the octicon resources checked in to our sources, so why is the fact that Octicons now ship as an NPM module an issue for us moving forward? Can we not just do the same? !
Yeah, copying the node-module isn't the blocker, tho weird, the issue is more that it's not a font anymore but 150+ svg-files which we need to bundle in a clever way.
Maybe has an idea on how to do that. I wonder if we can convert the set back to a font so that it is easy for us to consume it as we did before.
and I talked about how to convert the new svgs back into an icon font. We'd need to setup a project (probably in node) that would have the right modules to convert svgs into icons.

but we'd need to: Format the octicons file names to include their unicode Format the less/sass templates to match the old styles format Audit the changes from the old version of Octicons (renames/deletions/additions) Map all of the changes Also create local ttf file for users to install This would take some time to setup, but nonetheless it is very hacky. Github has already so this would be a patch that we'd need to maintain. One last thing to consider is if in the future we decide to create our own icon set (related to ) then this would be deprecated. I'd be in favor of putting our efforts into creating our own icon set that can be consumed by everyone.