Rozwiązywanie „nieoczekiwanego tokena „<” we wdrożeniu Angular i .NET 8

Gdy wdrożenie działa w debugowaniu, ale kończy się niepowodzeniem w usługach IIS

Czy kiedykolwiek spotkałeś się z frustracją związaną z tym, że Twoja aplikacja działa doskonale w trybie debugowania, ale po wdrożeniu kończy się niepowodzeniem? 😟 Może to być szczególnie irytujące podczas migracji projektu, czego ostatnio doświadczyłem podczas przenoszenia mojej aplikacji Angular i .NET z .NET Core 2.1 do .NET 8. Problem wydawał się tajemniczy: „Nieprzechwycony błąd składni: nieoczekiwany token”

Dziwna część? Sprawdzanie plików wdrożeniowych ujawniło, że niektóre skrypty — takie jak środowisko uruchomieniowe, wypełniacze i główne — były udostępniane jako pliki HTML zamiast JavaScript. To zachowanie sprawiło, że drapałem się po głowie, ponieważ lokalny folder „dist” pokazywał prawidłowy format JS. Jednak wdrożenie IIS pokazało zupełnie inny obraz.

Jako programista napotykanie takich niespójności przypomina rozwiązywanie zagadki, w której każdy trop otwiera kolejne mylące pytanie. Dokładnie sprawdziłem ścieżki, polecenia i konfiguracje, ale nie mogłem od razu określić przyczyny. W obliczu zbliżających się terminów rozwiązanie tego problemu stało się priorytetem. 🕒

W tym poście zagłębię się w pierwotną przyczynę tego problemu, podzielę się wnioskami, jakie wyciągnąłem podczas rozwiązywania problemów, i poprowadzę Cię przez jego skuteczne rozwiązanie. Jeśli spotkałeś się z podobnym scenariuszem, bądź na bieżąco — obiecuję, że nie jesteś sam w tej podróży!

Wyjaśnianie błędów wdrażania w aplikacjach Angular i .NET

W powyższych skryptach każde rozwiązanie koncentruje się na konkretnym aspekcie rozwiązywania problemów z wdrażaniem w środowisku Angular i .NET. Plik konfiguracyjny IIS przy użyciu web.config ma kluczowe znaczenie dla rozwiązywania niezgodności typów MIME. Poprzez jawne mapowanie rozszerzeń plików, takich jak `.js`, na ich właściwy typ MIME (aplikacja/javascript), IIS wie, jak poprawnie udostępniać te pliki przeglądarkom. Zapobiega to „Nieoczekiwanemu tokenowi”

The Polecenie budowania kątowego (kompilacja --prod) zapewnia optymalizację aplikacji pod kątem produkcji. Parametr `--output-hashing=all` miesza nazwy plików, umożliwiając przeglądarkom buforowanie plików bez przypadkowego użycia nieaktualnych wersji. Jest to szczególnie ważne w przypadku wdrożeń w świecie rzeczywistym, gdzie użytkownicy często ponownie odwiedzają aplikację. Konfigurując `baseHref` i `deployUrl` w `angular.json`, zapewniamy, że routing i ładowanie zasobów działają bezproblemowo, nawet jeśli są hostowane w podkatalogach lub sieciach CDN. Te kroki sprawiają, że aplikacja jest odporna na typowe wyzwania związane z wdrażaniem, poprawiając zarówno wygodę użytkownika, jak i niezawodność.

Dostarczony powyżej skrypt Node.js dodaje kolejną warstwę debugowania poprzez skanowanie katalogu `dist` w celu potwierdzenia integralności plików. Używając poleceń takich jak `fs.readdirSync` i `mime.lookup`, skrypt sprawdza przed wdrożeniem, czy każdy plik ma poprawny typ MIME. Ten proaktywny krok pomaga wychwycić potencjalne błędy, zanim pojawią się na produkcji, oszczędzając czas i zmniejszając frustrację. Na przykład podczas jednego z wdrożeń ten skrypt pomógł mi uświadomić sobie, że problem z konfiguracją doprowadził do udostępnienia plików JSON z niewłaściwym typem MIME! 🔍

Wreszcie skrypt testowy Jest zapewnia automatyczną weryfikację kluczowych aspektów wdrożenia. Sprawdza, czy w folderze `dist` znajdują się krytyczne pliki, takie jak `runtime.js` i `main.js`. Zapobiega to przeoczeniu błędów podczas wdrażania, szczególnie w środowiskach zespołowych, w których zaangażowanych jest wielu programistów. Uwzględniając takie testy, możesz śmiało wdrożyć aplikację, wiedząc, że została dokładnie sprawdzona. Rozwiązania te, użyte razem, tworzą solidny proces rozwiązywania problemów wdrożeniowych i zapewnienia płynnego wdrażania wersji produkcyjnych.

<!-- web.config solution to fix MIME type issues in IIS -->
<configuration>
  <system.webServer>
    <staticContent>
      <mimeMap fileExtension=".*" mimeType="application/octet-stream" />
      <mimeMap fileExtension=".js" mimeType="application/javascript" />
      <mimeMap fileExtension=".json" mimeType="application/json" />
    </staticContent>
  </system.webServer>
</configuration>

// Angular CLI commands to rebuild the application
ng build --prod --output-hashing=all
// Ensure deployment paths in angular.json are set correctly
{
  "outputPath": "dist/my-app",
  "baseHref": "/",
  "deployUrl": "/"
}
// Copy contents of dist folder to IIS hosted directory

// Node.js script to check MIME types of files in the dist folder
const fs = require('fs');
const path = require('path');
const mime = require('mime-types');
// Directory to check
const distDir = path.join(__dirname, 'dist');
// Function to validate file types
function validateFiles(dir) {
  fs.readdirSync(dir).forEach(file => {
    const fullPath = path.join(dir, file);
    if (fs.lstatSync(fullPath).isDirectory()) {
      validateFiles(fullPath);
    } else {
      const mimeType = mime.lookup(fullPath);
      console.log(`File: ${file}, MIME Type: ${mimeType}`);
    }
  });
}
validateFiles(distDir);

// Jest test to validate Angular dist folder integrity
const fs = require('fs');
const path = require('path');
test('All JavaScript files should exist and be served correctly', () => {
  const distDir = path.join(__dirname, 'dist');
  const requiredFiles = ['runtime.js', 'polyfills.js', 'main.js'];
  requiredFiles.forEach(file => {
    const filePath = path.join(distDir, file);
    expect(fs.existsSync(filePath)).toBe(true);
  });
});

Zrozumienie znaczenia statycznej konfiguracji plików podczas wdrażania

Jednym z kluczowych aspektów często pomijanych podczas wdrażania jest właściwa konfiguracja obsługi plików statycznych. W przypadku aplikacji Angular i .NET, aby aplikacja działała, zasoby statyczne takie jak pliki JavaScript i CSS muszą być poprawnie obsługiwane. Niewłaściwe ustawienia typu MIME na serwerze mogą prowadzić do błędów takich jak niesławny „Uncaught SyntaxError: Unexpected token”zawartość statyczna w konfiguracji IIS zapewnia poprawną interpretację tych plików. Takie konfiguracje na poziomie serwera są niezbędne, aby uniknąć niespodzianek w czasie wykonywania. 🚀

Innym aspektem do zbadania jest wpływ błędnej konfiguracji routingu. Aplikacje Angular korzystają z routingu po stronie klienta, co często powoduje konflikt z konfiguracjami serwerów oczekującymi predefiniowanych punktów końcowych. Dodanie tras awaryjnych w konfiguracji serwera, np. przekierowanie wszystkich żądań do pliku `index.html`, gwarantuje, że aplikacja nie ulegnie uszkodzeniu. Na przykład w IIS można to osiągnąć za pomocą rozszerzenia `` reguła, która kieruje wszystkie niedopasowane żądania do punktu wejścia Angular. Ten prosty, ale skuteczny krok może zaoszczędzić wiele godzin debugowania i poprawić niezawodność aplikacji. 🛠️

Na koniec rozważ rolę optymalizacji czasu kompilacji. Komenda Angulara „ng build” z flagami produkcyjnymi, takimi jak „--aot” i „--optimization”, kompiluje i minimalizuje aplikację w celu uzyskania lepszej wydajności. Kluczowe znaczenie ma jednak zapewnienie zgodności tych optymalizacji ze środowiskiem wdrożenia. Na przykład włączenie map źródłowych podczas wstępnego wdrożenia może pomóc w debugowaniu problemów w środowisku produkcyjnym bez narażania bezpieczeństwa w późniejszym czasie poprzez ich wyłączenie. Takie najlepsze praktyki sprawiają, że wdrożenia są bardziej przewidywalne i wydajne.