Вирішення «Неочікуваного токена «<» в розгортанні Angular і .NET 8

Коли розгортання працює в Debug, але не вдається в IIS

Ви коли-небудь стикалися з розчаруванням, спостерігаючи, як ваша програма ідеально працює в режимі налагодження, але з тріском збій під час розгортання? 😟 Це може бути особливо неприємним під час міграції проекту, як я нещодавно відчув під час переміщення своєї програми Angular і .NET з .NET Core 2.1 на .NET 8. Проблема здавалася загадковою: «Uncaught SyntaxError: Unexpected token»

Дивна частина? Перевірка файлів розгортання виявила, що деякі сценарії, такі як час виконання, полізаповнення та основний, обслуговувалися як файли HTML замість JavaScript. Ця поведінка змусила мене почухати голову, оскільки локальна папка `dist` показувала правильний формат JS. Однак розгортання IIS намалювало зовсім іншу картину.

Як розробнику, зіткнення з такими невідповідностями нагадує розгадку таємниці, де кожна підказка відкриває ще одне заплутане питання. Я ще раз перевірив шляхи, команди та конфігурації, але не зміг одразу визначити причину. З наближенням термінів вирішення цього питання стало пріоритетним. 🕒

У цій публікації я розповім про першопричину цієї проблеми, поділюся уроками, які я засвоїв під час усунення несправностей, і пропоную вам ефективно її вирішити. Якщо ви зіткнулися з подібним сценарієм, стежте за оновленнями — я обіцяю, що ви не самотні в цій подорожі!

Демістифікація помилок розгортання в програмах Angular і .NET

У сценаріях, наданих вище, кожне рішення зосереджено на певному аспекті усунення проблем із розгортанням у середовищі Angular і .NET. Файл конфігурації IIS за допомогою web.config має вирішальне значення для вирішення невідповідностей типу MIME. Явно зіставляючи розширення файлів, наприклад `.js`, із відповідним типом MIME (application/javascript), IIS знає, як правильно надавати ці файли браузерам. Це запобігає "Неочікуваний маркер"

The Команда побудови Angular (ng build --prod) забезпечує оптимізацію програми для виробництва. Параметр `--output-hashing=all` хешує імена файлів, дозволяючи браузерам кешувати файли без випадкового використання застарілих версій. Це особливо важливо в реальних розгортаннях, де користувачі часто переглядають програму. Налаштувавши `baseHref` і `deployUrl` у `angular.json`, ми гарантуємо безперебійну роботу маршрутизації та завантаження ресурсів, навіть якщо вони розміщені в підкаталогах або CDN. Ці кроки роблять програму стійкою до поширених проблем розгортання, покращуючи як взаємодію з користувачем, так і надійність.

Наданий вище сценарій Node.js додає ще один рівень налагодження шляхом сканування каталогу `dist` для підтвердження цілісності файлів. Використовуючи такі команди, як `fs.readdirSync` і `mime.lookup`, сценарій перевіряє, що кожен файл має правильний тип MIME перед розгортанням. Цей профілактичний крок допомагає виявляти потенційні помилки до того, як вони виникнуть у виробництві, заощаджуючи час і зменшуючи розчарування. Наприклад, під час одного з моїх розгортань цей сценарій допоміг мені зрозуміти, що проблема конфігурації призвела до того, що файли JSON обслуговуються з неправильним типом MIME! 🔍

Нарешті, сценарій тестування Jest забезпечує автоматичну перевірку ключових аспектів розгортання. Він перевіряє наявність критичних файлів, таких як `runtime.js` і `main.js`, у папці `dist`. Це запобігає помилкам, які не помічаються під час розгортання, особливо в командних середовищах, де задіяно кілька розробників. Використовуючи такі тести, ви можете впевнено розгортати свою програму, знаючи, що вона пройшла ретельну перевірку. Ці рішення, якщо їх використовувати разом, створюють надійний процес для вирішення проблем із розгортанням і забезпечення безперебійних виробничих випусків.

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

Розуміння важливості статичної конфігурації файлів у розгортанні

Одним із критичних аспектів, який часто ігнорують під час розгортання, є правильна конфігурація обробки статичних файлів. У випадку додатків Angular і .NET статичні ресурси, такі як файли JavaScript і CSS, повинні обслуговуватися правильно, щоб програма працювала. Неправильні налаштування типу MIME на сервері можуть призвести до таких помилок, як сумнозвісна «Uncaught SyntaxError: Unexpected token»staticContent у конфігурації IIS забезпечує правильну інтерпретацію цих файлів. Такі конфігурації на рівні сервера є незамінними, щоб уникнути сюрпризів під час виконання. 🚀

Інший кут для дослідження – це вплив неправильної конфігурації маршрутизації. Програми Angular використовують маршрутизацію на стороні клієнта, яка часто конфліктує з настройками сервера, які очікують попередньо визначених кінцевих точок. Додавання резервних маршрутів у конфігурації сервера, як-от перенаправлення всіх запитів до `index.html`, гарантує, що програма не зламається. Наприклад, у IIS цього можна досягти за допомогою `` правило, яке спрямовує всі невідповідні запити до точки входу Angular. Цей простий, але потужний крок може заощадити години налагодження та підвищити надійність вашої програми. 🛠️

Нарешті, розглянемо роль оптимізації часу збірки. Команда Angular `ng build` з такими прапорцями виробництва, як `--aot` і `--optimization`, компілює та мінімізує програму для кращої продуктивності. Однак ключовим є забезпечення відповідності цих оптимізацій середовищу розгортання. Наприклад, увімкнення вихідних карт під час початкового розгортання може допомогти усунути проблеми у виробництві без шкоди для безпеки пізніше, вимкнувши їх. Такі найкращі практики роблять розгортання більш передбачуваними та ефективними.