Add language config mappings from VSC extensions

[ghost]

The icon pack doesn't include extensions that can instead be associated with a reconfigurable language ID.

Let's pull in mutually exclusive language configuration data from Microsoft repos so that this data can be used to compute and apply icons accurately.

[shivapoudel]

@4086606 Just like we copied the material-icons.json into iconMap.json is there any repo we can look for to generate that language-related JSON it is because we don't wanna store those files here manually!

Currently, we clone the VSCode extension in a temporary directory and collect the material-icons.json from the vscode extension distribution folder to ours iconsMap.json. Additionally can you please sync with this PR https://github.com/Claudiohbsantos/github-material-icons-extension/pull/7/files and suggest how we can improve the language config mapping currently I had hardcoded the js and ts file extension to support icon here.

[ghost]

👀 Don't hardcode those please!

It's compiled from every contributes.languages in the Microsoft organisation:

• Search for "contributes languages filename:package.json org:microsoft"
• Download the files to ./temp/vs/{repo}/{path}
• Delete all files that fail this regex test: /([ \t]+)"languages": \[\n(.*\n)+?\1\]/
• Delete any folders with "sample" in the name
• Merge all the language arrays
• Convert valid filenamePatterns into extensions (regex /^\*\.[^*]+$/) and filenames (regex /^[^*]+$/)
• Convert into lang-config map: [{id:"",...}] -> "id":{...}
• Move any file extensions not prefixed with . into file names *
• Remove prefix . from all file extensions
• Remove anything that's mapped in material-icons.json *
• Do some remapping *
  • properties extensions ^git -> git
  • properties extensions ==editorconfig -> editorconfig
  • properties extensions ^npm -> npm
  • properties extensions -> settings
  • properties names -> git
  • vb -> visualstudio
  • tablegen -> fsharp (custom)
  • python -> python-misc (custom)
  • shellscript -> console
  • juliamarkdown -> julia (custom)
  • git-commit -> git
  • git-rebase -> git
  • ignore -> vscode (custom)
• Do some merging:
  • perl6 -> perl
  • jsonc -> json
• Do some deletions: *
  • Delete hlsl
  • Delete log extensions
  • Delete ignore extensions
• Remove definitions present in material-icons.json *

(Anything with a * after needs empty arrays removed as a post-completion step.)

[ghost]

(CC @Claudiohbsantos) ideally this PR would precede the work in #7 and get merged first

[ghost]

@shivapoudel I made the package able to generate the new config file automatically in b48d6fd ... 4da4285

[ghost]

I also switched away from the camelcase naming convention because this repo ships with JSON files

[Claudiohbsantos]

Thanks for the work on this. I'm travelling for a quick break until mid next week. I'll make sure to review this asap when I'm back

[ghost]

I would be ideal to run the build scripts and publish all that to a dev branch. I'll have that done in an hour.

[ghost]

@Claudiohbsantos done, see 4086606/github-material-icons-extension@dev.

It would be nice if you publish this branch to this repo and update it for each release or PR merge

[Claudiohbsantos]

Thanks for the changes. I'll merge this and then jump onto the other PR asap.

I'm not sure I understand the advantage of checking in generated files into git. Could you elaborate on how that would be better than having devs run the build scripts locally?

[ghost]

That's what Phillip does over at the main repo. It's honestly super useful if you can't run the build scripts or download Chromium.

[Claudiohbsantos]

@4086606 That makes sense. With the latest PR just merged downloading Chromium shouldn't be necessary anymore, which I believe will alleviate most of this issue. For now I'll hold off on checking in the generated files, just because I generally find more issues than benefits to having to wrangle them while navigating branches and their potentially different versions, and because I don't believe this project will have/need as much contribution as the VSCode extension, so I think keeping the repo simpler makes things easier for now. I appreciate the suggestion though, and will keep it in mind for the future 👍