Řešení 'Neočekávaný token '<' v Angular a .NET 8 Deployment

Když nasazení funguje v ladění, ale selže na IIS

Už jste někdy čelili frustraci, když jste viděli, že vaše aplikace funguje perfektně v režimu ladění, ale při nasazení selhává? 😟 To může být obzvláště nepříjemné při migraci projektu, jak jsem nedávno zažil při přesunu své aplikace Angular a .NET z .NET Core 2.1 na .NET 8. Problém se zdál záhadný: 'Uncaught SyntaxError: Unexpected token'

Zvláštní část? Kontrola souborů nasazení odhalila, že některé skripty – například runtime, polyfills a main – byly podávány jako soubory HTML namísto JavaScriptu. Toto chování mě poškrábalo na hlavě, protože místní složka `dist` ukazovala správný formát JS. Nasazení služby IIS však přineslo zcela odlišný obrázek.

Setkání s takovými nekonzistentnostmi jako pro vývojáře mi připadá jako řešení záhady, kde každá stopa otevírá další matoucí otázku. Znovu jsem zkontroloval cesty, příkazy a konfigurace, ale nemohl jsem okamžitě určit příčinu. S blížícími se termíny se řešení tohoto problému stalo prioritou. 🕒

V tomto příspěvku se ponořím do hlavní příčiny tohoto problému, podělím se o lekce, které jsem se naučil při odstraňování problémů, a provedu vás jeho efektivním řešením. Pokud jste se dostali do podobného scénáře, zůstaňte naladěni – slibuji, že na této cestě nejste sami!

Demystifikování chyb nasazení v Angular a .NET aplikacích

Ve výše uvedených skriptech se každé řešení zaměřuje na konkrétní aspekt řešení problémů s nasazením v prostředí Angular a .NET. Konfigurační soubor IIS pomocí web.config je zásadní pro řešení neshod typu MIME. Explicitním mapováním přípon souborů, jako je `.js`, na jejich správný typ MIME (aplikace/javascript), služba IIS ví, jak správně poskytovat tyto soubory prohlížečům. Tím se zabrání „neočekávanému tokenu“

The Příkaz úhlového sestavení (sestavení --prod) zajišťuje optimalizaci aplikace pro výrobu. Parametr `--output-hashing=all` hashuje názvy souborů, což prohlížečům umožňuje ukládat soubory do mezipaměti bez náhodného použití zastaralých verzí. To je zvláště důležité v reálném světě nasazení, kde uživatelé často znovu navštěvují aplikaci. Nakonfigurováním `baseHref` a `deployUrl` v `angular.json` zajistíme, že směrování a načítání prostředků bude fungovat hladce, i když je hostováno v podadresářích nebo CDN. Díky těmto krokům je aplikace odolná vůči běžným problémům s nasazením, což zlepšuje jak uživatelskou zkušenost, tak spolehlivost.

Výše uvedený skript Node.js přidává další vrstvu ladění skenováním adresáře `dist`, aby se potvrdila integrita souborů. Pomocí příkazů jako `fs.readdirSync` a `mime.lookup` skript před nasazením ověří, že každý soubor má správný typ MIME. Tento proaktivní krok pomáhá zachytit potenciální chyby dříve, než k nim dojde ve výrobě, šetří čas a snižuje frustraci. Například během jednoho z mých nasazení mi tento skript pomohl uvědomit si, že problém s konfigurací vedl k tomu, že soubory JSON byly poskytovány s nesprávným typem MIME! 🔍

A konečně testovací skript Jest zajišťuje automatické ověření klíčových aspektů nasazení. Kontroluje existenci kritických souborů jako `runtime.js` a `main.js` ve složce `dist`. To zabraňuje přehlédnutým chybám během nasazení, zejména v týmových prostředích, kde je zapojeno více vývojářů. Začleněním těchto testů můžete s jistotou nasadit svou aplikaci s vědomím, že byla důkladně ověřena. Tato řešení, pokud jsou použita společně, vytvářejí robustní proces pro řešení problémů s nasazením a zajištění hladkého produkčního vydání.

<!-- 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);
  });
});

Pochopení důležitosti konfigurace statického souboru při nasazení

Jedním z kritických aspektů, který je během nasazení často přehlížen, je správná konfigurace zpracování statických souborů. V případě aplikací Angular a .NET musí být statické prostředky, jako jsou soubory JavaScript a CSS, správně poskytovány, aby aplikace fungovala. Nesprávné nastavení typu MIME na serveru může vést k chybám, jako je nechvalně známý „Uncaught SyntaxError: Unexpected token“statický obsah v konfiguraci IIS zajišťuje správnou interpretaci těchto souborů. Takové konfigurace na úrovni serveru jsou nepostradatelné pro zamezení překvapení za běhu. 🚀

Dalším úhlem pohledu, který je třeba prozkoumat, je dopad chybných konfigurací směrování. Aplikace Angular používají směrování na straně klienta, které je často v konfliktu s nastavením serveru očekávajícího předdefinované koncové body. Přidání záložních tras do konfigurace serveru, jako je přesměrování všech požadavků na `index.html`, zajistí, že se aplikace nezlomí. Například v IIS toho lze dosáhnout pomocí `` pravidlo, které směruje všechny neshodné požadavky do vstupního bodu Angular. Tento jednoduchý, ale výkonný krok může ušetřit hodiny ladění a zlepšit robustnost vaší aplikace. 🛠️

Nakonec zvažte roli optimalizace doby sestavení. Příkaz `ng build` od Angularu s produkčními příznaky jako `--aot` a `--optimization` kompiluje a minimalizuje aplikaci pro lepší výkon. Klíčové je však zajištění souladu těchto optimalizací s prostředím nasazení. Například povolení zdrojových map během počátečního nasazení může pomoci ladit problémy v produkci, aniž by došlo k pozdějšímu ohrožení zabezpečení jejich deaktivací. Díky těmto osvědčeným postupům jsou nasazení předvídatelnější a efektivnější.