Learning path · Level 8 · Tutorial 1

Enable Strict Type Checking in a Local Vite Project

Add TypeScript to a local Vite project, enable strict checking, and extend the existing ESLint workflow to cover TypeScript source while keeping linting, type checking, and browser execution separate.

Level: Intermediate
Duration: 25 min
8 steps

Start tutorial Back to the path

What you will go through

Add TypeScript to the Local Project Prepare a compact local Vite baseline and add the TypeScript compiler without changing the existing Vite or ESLint roles. 3 min
Connect TypeScript Modules to Vite Rename the Study Session modules to TypeScript, update their explicit paths, and verify that Vite serves the unchanged browser result. 3 min
Configure Strict, No-Emit Checking Configure a strict TypeScript compiler check for browser source without producing JavaScript files. 4 min
Use Inferred and Explicit Primitive Types Read inferred primitive types, write explicit annotations, and distinguish static type contracts from runtime conversion. 3 min
Read and Repair Type Errors Locate TypeScript assignment diagnostics, repair primitive values without weakening strict checking, and verify the fixes with a separate compiler run. 3 min
Extend ESLint to TypeScript Source Extend the existing ESLint flat configuration so it checks authored TypeScript without losing JavaScript, environment, or ignore coverage. 5 min
Distinguish Lint, Type Check, and Browser Results Use two controlled defects to compare ESLint diagnostics, TypeScript compiler diagnostics, and Vite browser execution. 3 min
Verify the Complete Local Workflow Repair and verify the complete local Vite, TypeScript, and ESLint workflow using separate evidence from each tool. 3 min

What you will learn

Configure a local Vite project to load a TypeScript entry module and check its source with strict compiler settings.
Use inferred and explicit primitive types to identify and correct incompatible assignments.
Update the existing ESLint flat configuration and lint command to check authored .ts files with an appropriate parser and recommended TypeScript rules.
Run separate lint and type-check commands and distinguish the problems each reports.
Explain why a page running through Vite does not establish that its TypeScript checks have passed.

Before you start

Prepare a Local Project with Node.js and npm
Manage npm Dependencies and Lockfiles
Run a Local Development Server with Vite
Split Browser Code into JavaScript Modules
Check JavaScript with ESLint
Work with JavaScript Values and Variables

Step 1 of 8

Add TypeScript to the Local Project

Prepare a compact local Vite baseline and add the TypeScript compiler without changing the existing Vite or ESLint roles.

Start from a local Vite copy

Prepare the practice project

Work in a local practice copy of an existing vanilla Vite project named study-session. Keep its ESM setup, including "type": "module" in package.json.

This step establishes a small, known baseline. You will keep Vite as the development server and keep the existing ESLint workflow. Installing TypeScript adds a project-local compiler tool; it does not replace either tool.

Project layout

A folder tree showing study-session with root HTML and configuration files, plus main.js and session.js inside src. — The HTML entry stays at the project root. Authored browser modules begin in `src/`; configuration files and package scripts stay at the root.

Add the baseline source files

Create the Study Session baseline

Use these complete baseline files in study-session. They render one Study Session line without needing a starter download. Keep package.json and eslint.config.js from the existing Vite project unchanged for now.

HTML entry

index.html

html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Study Session</title>
  </head>
  <body>
    <script type="module" src="/src/main.js"></script>
  </body>
</html>

Supporting module

src/session.js

javascript

export const sessionTitle = "TypeScript practice";

Entry module

src/main.js

javascript

import { sessionTitle } from "./session.js";

let minutes = 25;
minutes = 30;
const remindersEnabled = true;

const sessionText = `Session: ${sessionTitle} | Minutes: ${minutes} | Reminders: ${remindersEnabled}`;
const sessionElement = document.createElement("p");
sessionElement.textContent = sessionText;
document.body.append(sessionElement);

Preserve the development workflow

Install the local compiler

From the study-session project root, install the compiler as a development dependency. npm records it in the local project and lockfile.

Vite still transforms and serves the page during development. TypeScript is now available locally, but you will configure and run its checking separately in a later step.

Install command

Run from the study-session project root.

bash

npm install -D typescript

Expected output

added 1 package, and audited 101 packages in 1s

found 0 vulnerabilities

The number of added packages, audit count, timing, and TypeScript version can vary by project and npm version. A successful install normally ends without an npm error.

Tip

Keep each tool's role

Do not replace the Vite development script with a compiler command. Keep "dev": "vite", continue using npm run dev for the browser, and leave the existing ESLint configuration and lint workflow in place.

Confirm the local preparation

Check the setup

Complete the local installation command and identify the two current source files planned for conversion in the next step.

bash

npm install -D 

# Source file 1 planned for conversion: src/ → src/main.ts
# Source file 2 planned for conversion: src/ → src/session.ts

Step 2 of 8

Connect TypeScript Modules to Vite

Rename the Study Session modules to TypeScript, update their explicit paths, and verify that Vite serves the unchanged browser result.

Rename the modules

Rename the authored modules

In your local study-session project, rename these authored source files:

src/main.js → src/main.ts
src/session.js → src/session.ts

Use your editor’s rename action or rename the files in your file manager. Keep the code JavaScript-compatible for now: TypeScript can load ordinary JavaScript syntax in a .ts file.

The HTML file remains at the project root. The renamed entry module will import the renamed supporting module.

A diagram of index.html loading main.ts, main.ts importing session.ts, and Vite serving the result to a browser. — Vite follows the module references, transforms the TypeScript modules, and serves the page to the browser.

Keep the Study Session behavior

Update the TypeScript source modules

After renaming, update the local module reference in src/main.ts so it names the .ts file. Keep the Study Session values and DOM rendering unchanged.

Save both files after replacing their contents with the versions below.

src/session.ts

Save as src/session.ts

typescript

export const sessionTitle = "TypeScript practice";

src/main.ts

Save as src/main.ts

typescript

import { sessionTitle } from "./session.ts";

let minutes = 25;
minutes = 30;

const remindersEnabled = true;
const sessionSummary = `Session: ${sessionTitle} | Minutes: ${minutes} | Reminders: ${remindersEnabled}`;
const sessionMessage = document.createElement("p");

sessionMessage.textContent = sessionSummary;
document.body.append(sessionMessage);

Run the converted entry

Point HTML at the TypeScript entry

Now change the module script in the root index.html so Vite starts from src/main.ts. The browser still loads one module entry; Vite resolves its local .ts dependency and transforms the modules for browser execution.

This conversion does not change the intended page text. Configuration for compiler checking of explicit .ts paths comes in the next step.

index.html

Replace the root index.html with this complete file.

html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Study Session</title>
  </head>
  <body>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

Run the local server

From the project root, start the existing Vite development server and open the local address it prints.

bash

npm run dev

Expected output

> study-session@1.0.0 dev
> vite

  VITE vX.X.X  ready in XXX ms

  ➜  Local:   http://localhost:5173/

The Vite version, startup time, and local port can vary. Leave this command running while you inspect the page.

Check the module connection

Verify your local conversion

In your local project, confirm the renamed files are saved and the Vite page is open. Then write the exact HTML module path and the exact local import path you used. Finally, report whether the expected Study Session text appears in your browser, including the text you see.

Write at least 50 characters (0/50).

Step 3 of 8

Configure Strict, No-Emit Checking

Configure a strict TypeScript compiler check for browser source without producing JavaScript files.

Define the checking boundary

One configuration, two tools

Create one root-level tsconfig.json for the browser TypeScript source. It tells the TypeScript compiler what to check; it does not control whether Vite can serve the page.

strict enables TypeScript’s broader family of stricter checks. Treat it as a compile-time safety setting, not as a browser feature. The individual checks within that family are explored later.

The include pattern limits this compiler project to authored .ts files under src. Existing JavaScript remains in the ESLint workflow rather than becoming part of this TypeScript check.

Checking is separate from serving

A diagram shows TypeScript checking source files without creating output while a development server transforms source files for a browser separately. — The compiler checks configured TypeScript source; Vite transforms and serves it during development.

Add the compiler configuration and script

tsconfig.json

At the project root, create tsconfig.json with this complete browser-oriented configuration.

json

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "allowImportingTsExtensions": true,
    "strict": true,
    "noEmit": true
  },
  "include": ["src/**/*.ts"]
}

Why these settings fit Vite

lib supplies modern JavaScript and browser declarations. module: "ESNext" and moduleResolution: "Bundler" match this Vite module project.

allowImportingTsExtensions permits the existing explicit .ts import path in src/main.ts. It fits this check-only workflow because noEmit prevents tsc from writing JavaScript; Vite remains responsible for browser transformation.

package.json scripts

In package.json, retain your other package fields and set the scripts to this standardized set.

json

{
  "scripts": {
    "dev": "vite",
    "typecheck": "tsc --noEmit",
    "lint": "eslint ."
  }
}

Check the essential settings

Complete the checking boundary

Complete the settings that define the strict, no-emit TypeScript checking boundary.

json

{
  "compilerOptions": {
    "allowImportingTsExtensions": ,
    "strict": ,
    "noEmit": 
  },
  "include": []
}

Run and interpret the dedicated check

Run the first type check

After saving tsconfig.json and the package script, run this dedicated check from the study-session project root.

bash

npm run typecheck

Expected output

> study-session@1.0.0 typecheck
> tsc --noEmit

The package version shown by npm can differ. On success, TypeScript produces no diagnostics and returns to your prompt.

Interpret a successful result

A quiet successful command means the included TypeScript files passed this compiler check. It does not create JavaScript output because noEmit prevents emission.

Use npm run dev separately to serve the page through Vite. A page in the browser shows that Vite transformed and executed the source; it does not establish that this independent type-check command passed.

Verify your local configuration

Apply the no-emit workflow

In your local study-session project, verify the strict-checking configuration and the typecheck package script, then run the script from the project root. Write a short report that identifies the settings for strict checking, no output, explicit .ts imports, and TypeScript source inclusion; records the command and result you observed; and explains why no JavaScript output files were created.

Write at least 180 characters (0/180).

Step 4 of 8

Use Inferred and Explicit Primitive Types

Read inferred primitive types, write explicit annotations, and distinguish static type contracts from runtime conversion.

Infer the type from the first value

Inference from an initializer

Inference starts with an initialized value. In the Study Session entry module, let minutes = 25; gives minutes the primitive type number. A later assignment must therefore be another number.

TypeScript uses this static information while checking your source. It does not wait for the browser to run the page.

One variable, one inferred primitive type

Diagram showing a variable initialized with 25 being treated as a number, while a later string assignment is blocked during type checking. — The initializer establishes the inferred primitive type; a later value of a different primitive type is not accepted.

The inferred type of minutes

In src/main.ts, the initialized let binding infers number. The later numeric reassignment remains compatible.

typescript

let minutes = 25;
minutes = 30;

Write annotations without changing runtime values

State an intended primitive contract

Use a colon annotation when you want to state a primitive contract explicitly: name: type. The available primitive annotations here are lowercase string, number, and boolean.

Annotations are useful when the intended type deserves to be visible. Do not add them mechanically to every declaration when a clear initializer already communicates the type.

Explicit primitive annotations

These annotations keep the Study Session values clear while preserving the same runtime values.

typescript

// src/session.ts
export const sessionTitle: string = "TypeScript practice";

// src/main.ts
let minutes: number = 25;
minutes = 30;

const remindersEnabled: boolean = true;

Tip

Types are not runtime conversion

A type annotation is removed when TypeScript is transformed for the browser. It does not convert a value, add browser validation, or make a string become a number.

For example, writing minutes: number expresses a checking rule; it does not convert the runtime value "30" into 30. Keep the numeric value numeric instead.

Primitive annotation reference

Choose the annotation that matches the value contract.

Colon annotations describe the values a declaration may hold.
Annotation	Compatible value example	Study Session use
string	"TypeScript practice"	sessionTitle
number	25 or 30	minutes
boolean	true	remindersEnabled

Practice the colon syntax

Complete the annotations

Complete the three primitive annotations.

typescript

const sessionTitle:  = "TypeScript practice";
let minutes:  = 25;
const remindersEnabled:  = true;

Apply primitive contracts

Match declarations to compatible values

Match each declaration to a compatible assignment or value.

Tap an item and then its matching pair.

Step 5 of 8

Read and Repair Type Errors

Locate TypeScript assignment diagnostics, repair primitive values without weakening strict checking, and verify the fixes with a separate compiler run.

Repair a mismatched declaration

Find the declaration mismatch

A primitive contract is checked where you declare it and wherever you assign a new value later. Start with a declaration mismatch in src/main.ts:

const remindersEnabled: boolean = "true";

The annotation requires a boolean, but the quoted value is a string. When you run npm run typecheck, TypeScript reports TS2322. Read the diagnostic as a comparison: the value supplied is the actual type; the annotation is the expected type.

Do not turn off strict to hide this. Decide what the session value is intended to mean, then edit the value to match that intended primitive.

Repair the declaration

const remindersEnabled: boolean = true;

Read TS2322 as a type comparison

Diagram showing a string value conflicting with a boolean annotation in a TypeScript declaration. — Use the file and location to find the code, then compare the actual value type with the type the declaration requires.

Fix without weakening checking

Repair a later assignment

A later assignment must also satisfy the type established for its variable. In this Study Session code, minutes starts with a number, so TypeScript keeps its inferred type as number.

If a later edit changes the assignment to minutes = "30";, TS2322 reports an actual string where number is expected. The quotation marks matter: they create a string; they do not represent a numeric value to TypeScript.

Fix the intended value, then run npm run typecheck again. A successful no-emit check normally finishes with no compiler diagnostics and creates no output files.

Numeric reassignment

let minutes = 25;
minutes = 30;

Tip

Edit, check, repair

Use a focused loop:

Run the type checker.
Open the reported file and location.
Compare the actual and expected primitive types.
Edit the value to express the intended data.
Run npm run typecheck again.

The checker verifies compatibility; Vite still handles transformation and serving separately.

Apply the two repairs

Repair both primitive mismatches

Complete the two value edits so this module has no primitive assignment mismatches.

import { sessionTitle } from "./session.ts";

let minutes = 25;
minutes = ;
const remindersEnabled: boolean = ;

const status = document.createElement("p");
status.textContent = `Session: ${sessionTitle} | Minutes: ${minutes} | Reminders: ${remindersEnabled}`;
document.body.append(status);

Order the verification workflow

Confirm the fixes

Put the edit-and-verification actions in the order that confirms the two repairs.

Run npm run typecheck and confirm that no diagnostics remain.
Open the diagnostic's reported file and location.
Compare the actual type with the expected type.
Edit the value to match the intended primitive contract.

Step 6 of 8

Extend ESLint to TypeScript Source

Extend the existing ESLint flat configuration so it checks authored TypeScript without losing JavaScript, environment, or ignore coverage.

Install and preserve the workflow

Add the TypeScript ESLint integration

Install the TypeScript ESLint integration from the study-session project root:

npm install -D typescript-eslint

This package provides a TypeScript parser, TypeScript-aware recommended rules, and flat-config presets. It extends the existing ESLint setup; it does not replace Vite, tsc, or JavaScript linting.

Keep the lint script as "lint": "eslint .". File patterns in the flat config determine which authored files that command checks.

One command, scoped file coverage

Diagram showing ESLint checking JavaScript and TypeScript source with browser globals, checking the configuration file with Node globals, and ignoring generated folders. — The flat config assigns environments and rules by file scope; `eslint .` discovers files according to those scopes.

Tip

Keep the tools separate

The TypeScript recommended preset is syntax-based here. It can parse .ts and apply TypeScript-focused rules, but it does not read tsconfig.json as a type-aware lint project. Keep npm run typecheck as the separate strict compiler check.

Configure source, tooling, and exclusions

Scope each part of the flat config

Replace the root eslint.config.js with the complete flat configuration below. The shared JavaScript recommended rules come first for authored source. The TypeScript configurations come afterward, so their TypeScript-specific rule adjustments apply to .ts files.

eslint.config.js

Root file: eslint.config.js

javascript

import js from "@eslint/js";
import globals from "globals";
import tseslint from "typescript-eslint";

export default [
  {
    ignores: ["dist/**", "node_modules/**"],
  },
  {
    files: ["src/**/*.{js,ts}"],
    ...js.configs.recommended,
    languageOptions: {
      globals: globals.browser,
    },
  },
  ...tseslint.configs.recommended.map((config) => ({
    ...config,
    files: ["src/**/*.ts"],
  })),
  {
    files: ["eslint.config.js"],
    ...js.configs.recommended,
    languageOptions: {
      globals: globals.node,
    },
  },
];

What each scope protects

Each block has a distinct responsibility. The source block intentionally includes both extensions; TypeScript rules are an additional, narrower layer rather than a replacement.

File scopes keep browser code, tooling, and generated files separate.
Files	Rules and parser	Globals
src/*/.js and src/*/.ts	JavaScript recommended rules	Browser
src/*/.ts	TypeScript recommended configurations	Inherited browser scope
eslint.config.js	JavaScript recommended rules	Node
dist/ and node_modules/	Ignored	None

Practice the scoped configuration

Complete the extension

Complete the missing scopes, preset name, and environment globals.

javascript

import js from "@eslint/js";
import globals from "globals";
import tseslint from "typescript-eslint";

export default [
  {
    ignores: ["dist/**", "node_modules/**"],
  },
  {
    files: ,
    ...js.configs.recommended,
    languageOptions: {
      globals: globals.,
    },
  },
  ...tseslint.configs..map((config) => ({
    ...config,
    files: ,
  })),
  {
    files: ["eslint.config.js"],
    ...js.configs.recommended,
    languageOptions: {
      globals: globals.,
    },
  },
];

Check a real TypeScript lint result

Verify TypeScript lint coverage

Save the completed configuration. In src/main.ts, temporarily add this unused binding on its own line:

const unusedNote = "draft";

From the project root, run npm run lint, then remove the temporary line.

Submit a three-line report:

The rule name and file extension reported by the lint result.
How the configuration continues to lint both authored JavaScript and TypeScript source.
One configuration change that would either drop JavaScript source coverage or apply the wrong globals to the tooling file, plus its consequence.

Write at least 80 characters (0/80).

Step 7 of 8

Distinguish Lint, Type Check, and Browser Results

Use two controlled defects to compare ESLint diagnostics, TypeScript compiler diagnostics, and Vite browser execution.

Separate the three observations

Three independent tools

Lint, Type check, and Browser are three separate observations of the same local source.

Lint: npm run lint applies configured ESLint rules.
Type check: npm run typecheck asks TypeScript to check compatibility without writing output.
Browser: npm run dev has Vite transform and serve the application.

Starting the dev server does not automatically run either of the other scripts. A page that appears in the browser is evidence that transformed JavaScript executed; it is not evidence that linting or TypeScript checking passed.

Separate evidence paths

A source file branches to a lint inspection, a type compiler inspection with no output file, and a Vite transformation that reaches a browser window. — The same source can produce different observations because each path asks a different question.

What each result establishes

Each result has a boundary. Static checks reduce mistakes but do not prove every runtime outcome is correct.

Use the tool result that matches the question you are asking.
Observation	Command	Evidence	Does not establish
Lint	npm run lint	Configured rule violations	Type compatibility or browser behavior
Type check	npm run typecheck	TypeScript compatibility under tsconfig.json	That the interface behaves correctly at runtime
Browser	npm run dev	Vite transformed code that the browser can execute	That lint and type checks were run or passed

Observe an ESLint-only defect

Defect 1: an unused binding

Begin with the repaired Study Session baseline. In src/main.ts, add the following local binding after remindersEnabled. Do not change the minutes = 30; assignment yet.

Add one unused declaration

Local context in src/main.ts

typescript

const remindersEnabled = true;
const unusedNote = "draft";

Record the contrast

Run npm run lint, then run npm run typecheck from the project root.

Lint reports unusedNote through @typescript-eslint/no-unused-vars.

Type check succeeds without a diagnostic: this project deliberately leaves noUnusedLocals and noUnusedParameters unset.

The declaration is valid JavaScript, so the Browser can still render the Study Session page. Remove unusedNote before the next observation so the defects remain independent.

Observe a compiler-only defect

Defect 2: an incompatible assignment

With unusedNote removed, replace only the numeric reassignment in src/main.ts with this incompatible assignment. Keep the original numeric initializer unchanged.

Change the reassignment

The local variable was initialized with a number, so its inferred type remains number.

typescript

let minutes = 25;
minutes = "30";

Compare the second result

Now run npm run lint, npm run typecheck, and inspect the page through npm run dev.

Lint can pass with the configured recommended, syntax-based TypeScript rules. Type check reports TS2322: a string is not assignable to the expected number type. Yet Vite can transform this syntactically valid source, and the Browser can display Session: TypeScript practice | Minutes: 30 | Reminders: true because interpolating the string produces the same visible characters.

Vite does not use this page render as a type-check result. Type information is erased during transformation; it does not convert a string into a number or add runtime validation.

Tip

Keep the evidence scoped

The two controlled defects demonstrate why command success must be interpreted by tool:

An unused binding is a configured lint concern here, not a compiler concern.
An incompatible primitive assignment is a compiler concern here, even when the browser can execute the transformed code.

After observing the result, restore minutes = 30; so the project returns to its baseline.

Practice: collect the evidence

Run and explain the independent checks

Starting from the repaired baseline, perform both observations yourself, one at a time:

Add the unused local binding and record the result from Lint, Type check, and Browser. Then remove that binding.
Introduce the incompatible minutes reassignment and again record all three results. Inspect the page while the defect is present, then restore the numeric reassignment.

In your response, compare the recorded results for both defects and explain why the page can render during the second defect even though the type-check command fails.

Write at least 250 characters (0/250).

Step 8 of 8

Verify the Complete Local Workflow

Repair and verify the complete local Vite, TypeScript, and ESLint workflow using separate evidence from each tool.

Apply the repair brief

Repair the entry module

Your final repair brief uses the established local study-session project. Temporarily replace src/main.ts with the supplied version, then repair all three defects without changing tsconfig.json, eslint.config.js, or the npm scripts:

Make the import name the real supporting TypeScript module.
Keep the later minutes value numeric.
Remove the unused draft binding.

The supporting file remains src/session.ts and continues to export the existing sessionTitle value. This brief combines module resolution, type compatibility, and a configured lint rule.

src/main.ts — defects to repair

Save this temporary version as src/main.ts before performing the repair.

typescript

import { sessionTitle } from "./sessions.ts";

let minutes = 25;
minutes = "30";
const remindersEnabled = true;
const unusedNote = "draft";

const sessionSummary = `Session: ${sessionTitle} | Minutes: ${minutes} | Reminders: ${remindersEnabled}`;
const sessionMessage = document.createElement("p");

sessionMessage.textContent = sessionSummary;
document.body.append(sessionMessage);

Three focused repairs

A diagram shows a corrected module link, a numeric assignment, and removal of an unused local binding. — Repair the module reference, the primitive assignment, and the unused binding while preserving the checking configuration.

Audit, do not weaken

Confirm the workflow guardrails

Do not solve the brief by weakening the guardrails. Audit the existing root configuration before verification. The compiler remains strict and check-only, while ESLint keeps shared browser-source coverage, adds TypeScript rules only to authored .ts files, and checks its JavaScript configuration as Node tooling.

Final configuration audit

Use this checklist to confirm that the existing configuration still has the intended boundaries.

Keep these settings in place while repairing source code.
Area	Required audit result
Compiler strictness	`strict` is true
Compiler output	`noEmit` is true
Compiler source scope	`include` is `src/*/.ts`
Shared source linting	`src/*/.{js,ts}` uses recommended JavaScript rules and browser globals
TypeScript linting	Recommended TypeScript configurations are mapped to `src/*/.ts`
Tooling linting	`eslint.config.js` uses JavaScript rules and Node globals
Global exclusions	`dist/` and `node_modules/` are ignored
Separate scripts	`dev`, `typecheck`, and `lint` remain separate

Run and inspect each tool

Verify each tool independently

First, with the supplied defective entry module still saved, run Type check once. It must fail because ./sessions.ts does not name the existing supporting source file. You do not need to interpret a diagnostic code: this failure simply confirms that the module-reference repair is required.

Then make all three source repairs and save the file. From the project root, run the three commands below. After the repair, Lint and Type check should complete without diagnostics. Start Browser separately and inspect the local Vite address. The dev server does not run either static-check command automatically.

Run the completed local workflow

Run these commands from the study-session project root after completing the three repairs.

bash

npm run lint
npm run typecheck
npm run dev

Expected output

> study-session@1.0.0 lint
> eslint .

> study-session@1.0.0 typecheck
> tsc --noEmit

> study-session@1.0.0 dev
> vite

  VITE ready
  Local: http://localhost:5173/

Package versions, startup time, and the available local port can vary. The important evidence is no lint or compiler diagnostics, followed by a running Vite server that you inspect in the browser.

Independent verification paths

A repaired source file leads separately to linting, type checking, and a browser preview. — Expected Browser display: Session: TypeScript practice | Minutes: 30 | Reminders: true

Summary

Completed workflow review

Vite transforms and serves TypeScript modules for Browser execution.
TypeScript checks compatibility under strict settings through npm run typecheck and writes no output in this workflow.
ESLint applies configured rules through npm run lint, including TypeScript rules for authored .ts files.
A page that runs is Browser evidence only; it does not prove that Lint or Type check passed.

Report the completed workflow

Final workflow verification

Complete the three repairs locally, then submit a concise verification report. Include:

the module-reference, primitive-assignment, and unused-binding repairs you made without changing configuration;
the separate result of Lint and Type check after the repair;
the exact Browser display you observed; and
why a working Browser page alone is insufficient evidence that TypeScript checks passed.

Write at least 180 characters (0/180).

Complete

Congratulations! You completed: Enable Strict Type Checking in a Local Vite Project

Well done. You can now keep Browser execution, TypeScript compatibility checks, and ESLint rule checks as separate evidence in a local Vite project.

50 XP

Next tutorial

Define Reusable Object and Array TypesDescribe records and collections with reusable TypeScript contracts, then share those contracts between modules without creating runtime data.18 min

Continue Previous tutorial: Prevent Outdated Requests from Updating the Interface

Download the App now to have access to + 5000 free courses, exercises, certificates and lots of content without paying anything!

100% free online courses from start to finish

Thousands of online courses in video, ebooks and audiobooks.
More than 60 thousand free exercises

To test your knowledge during online courses
Valid free Digital Certificate with QR Code

Generated directly from your cell phone's photo gallery and sent to your email

Download our app via QR Code or the links below:.