Jak zrobić VS Code, aby traktował inne rozszerzenia plików jako określony język?

Czy jest sposób na zmianę języka bieżącego pliku, aby użyć funkcji podświetlania składni?

Na przykład *.jsxfaktycznie używa JavaScript, ale VS Code go nie rozpoznaje.

W programie Visual Studio Code możesz dodać trwałe skojarzenia plików do podświetlania języka do swojego settings.jsonpliku w następujący sposób:

// Place your settings in this file to overwrite the default settings
{
  "some_setting": custom_value,
  ...

  "files.associations": {
    "*.thor": "ruby",
    "*.jsx": "javascript",
    "Jenkinsfile*": "groovy"
  }
}

Możesz użyć Ctrl+ Shift+, pa następnie pisać settings JSON. Wybierz Preferencje: Otwórz ustawienia (JSON), aby otworzyćsettings.json .

Ta Files: Associationsfunkcja została po raz pierwszy wprowadzona w Visual Studio Code wersja 1.0 (marzec 2016 r.). Sprawdź dostępne wzory symboli wieloznacznych w informacjach o wersji i znane ciągi językowe w dokumentacji.

Przytrzymaj Ctrl + Shift + P (lub cmd na Macu), wybierz „Zmień tryb językowy” i gotowe.

Ale nadal nie mogę znaleźć sposobu, aby pliki VS Code rozpoznawały pliki z określonym rozszerzeniem jako określony język.

Najłatwiejszy sposób, jaki znalazłem dla globalnego skojarzenia, to po prostu ctrl + km (lub ctrl + shift + p i wpisz „zmień tryb językowy”) z plikiem typu, który kojarzysz, otwórz.

W pierwszych opcjach będzie „Skonfiguruj skojarzenie pliku dla 'x'” (niezależnie od typu pliku - patrz obraz w załączeniu) Wybranie tego powoduje trwałe powiązanie typu pliku

Mogło się to zmienić (prawdopodobnie tak zrobiło) od czasu pierwotnego pytania i zaakceptowanej odpowiedzi (i nie wiem, kiedy to się zmieniło), ale jest to o wiele łatwiejsze niż ręczne edytowanie kroków w zaakceptowanych i niektórych innych odpowiedziach i całkowicie unika do musów z identyfikatorami, które mogą nie być oczywiste.

na przykład:

// .vscode/settings.json in workspace

{
  "files.associations": {
    "*Container.js": "javascriptreact",
    "**/components/*/*.js": "javascriptreact",
    "**/config/routes.js": "javascriptreact"
  }
}

To działa dla mnie.

{
"files.associations": {"*.bitesize": "yaml"}
 }

Spowoduje to na przykład, że pliki zakończą się na .variablesi.overrides traktowane jak każdy inny plik LESS. Pod względem kolorystyki kodu, pod względem formatowania (automatycznego). Zdefiniuj w ustawieniach użytkownika lub ustawieniach projektu, jak chcesz.

(Interfejs semantyczny używa tych dziwnych rozszerzeń, na wypadek gdybyś się zastanawiał)

Znalazłem rozwiązanie tutaj: https://code.visualstudio.com/docs/customization/colorizer

Przejdź do VS_CODE_FOLDER/resources/app/extensions/i tam zaktualizujpackage.json

Postępowanie zgodnie z instrukcjami na https://code.visualstudio.com/docs/customization/colorizer#_common-questions działało dobrze dla mnie:

Aby rozszerzyć istniejący program do kolorowania, należy utworzyć prosty pakiet.json w nowym folderze w .vscode / extensions i podać atrybut extensionDependencies określający dostosowanie, które chcesz dodać. W poniższym przykładzie rozszerzenie .mmd zostało dodane do kolorystyki przecenionej. Zauważ, że nazwa rozszerzeniaDzależność musi nie tylko pasować do dostosowania, ale także identyfikator języka musi być zgodny z identyfikatorem języka rozszerzanego programu do kolorowania.

{
    "name": "MyMarkdown",
    "version": "0.0.1",
    "engines": {
        "vscode": "0.10.x"
    },
    "publisher": "none",
    "extensionDependencies": [
        "markdown"
    ],
    "contributes": {
        "languages": [{
            "id": "markdown",
            "aliases": ["mmd"],
            "extensions": [".mmd"]
        }]
    }
}

Zastosowałem inne podejście do rozwiązania tego samego problemu, w moim przypadku stworzyłem nowe rozszerzenie, które dodaje obsługę podświetlania składni PHP dla plików specyficznych dla Drupala (takich jak .module i .inc): https: // github. com / mastazi / VS-code-drupal

Jak widać w kodzie, stworzyłem nowe rozszerzenie zamiast modyfikować istniejące rozszerzenie PHP. Oczywiście deklaruję zależność od rozszerzenia PHP w rozszerzeniu Drupal.

Zaletą robienia tego w ten sposób jest to, że jeśli istnieje aktualizacja rozszerzenia PHP, moje niestandardowe wsparcie dla Drupala nie gubi się w procesie aktualizacji.