TypeScript中export/import使用疑问：未导出类为何可跨文件访问？

Great question—this is such a common gotcha when you’re first getting your feet wet with TypeScript, so let’s unpack it clearly.

Why un-exported classes work without imports #

The key here is understanding the difference between scripts and modules in TypeScript (and JavaScript):

• If a file has no import or export statements anywhere, TypeScript treats it as a global script. Everything you define in that file (classes, functions, variables) gets added to the global scope. That’s why your un-exported classes are available in other script files without needing imports—they’re just sitting in the global namespace.
  For example:

  // user.ts (no imports/exports = global script)
  class User {
    name: string;
    constructor(name: string) {
      this.name = name;
    }
  }
  

  // app.ts (also a global script)
  const myUser = new User(); // Works! User is in the global scope
  

• As soon as you add any import or export to a file, it becomes an ES module. Modules have their own isolated scope—nothing inside is accessible from outside unless you explicitly export it. That’s why files with imports force you to use export/import to share code.

Is this "no export/import" approach okay to use? #

Short answer: It depends on the size of your project, but it’s almost always better to avoid it long-term.

• For tiny, throwaway scripts or super simple projects: It might work temporarily, but you’re playing with fire. Global scope is a breeding ground for naming conflicts (e.g., if two files define a User class, you’ll get a runtime error).
• For any project you plan to grow or maintain: Don’t do it. Modules are the standard for modern JavaScript/TypeScript development—they keep your code organized, prevent naming collisions, and make it easier to reason about dependencies.

When must you use export? #

You’ll need to use export (and corresponding imports) in these scenarios:

• When your file is a module (has any import/export statement). Without export, none of its internal members are visible to other modules.
• When you want to enforce encapsulation. Export only the parts of your code that other files need to use—keep internal helper classes/functions private to avoid cluttering your public API.
• When using module bundlers like Webpack, Vite, or Rollup. These tools treat every file as a module by default, so global scope tricks won’t work at all.
• When working with TypeScript’s module compiler option set to anything other than none (which is the default for most modern setups).

Final takeaway #

While the global script behavior is convenient for quick tests, it’s not a scalable practice. Get in the habit of treating every file as a module—use export for members you need to share, and import to bring them into other files. It’ll save you from messy bugs and make your codebase much easier to maintain as it grows.

内容的提问来源于stack exchange，提问作者mp9007