Visual Studio共享项目与类库区别及TS6059编译错误解决咨询

Hey there! Let's tackle your two questions step by step to get things working smoothly.

First, let's clear up how these two project types differ—especially since you're using shared projects for front-end assets like React components, JS, and CSS, this context matters:

• Core Purpose & Functionality
  Shared projects are built for source-level code sharing: when you reference one, its files act as if they're directly part of the referencing project. They don't compile on their own; they piggyback on the referencing project's build setup. This is perfect for your use case, as it lets your TS/JS/CSS files integrate seamlessly into each web project's build pipeline.

  Class libraries, by contrast, compile into a standalone .dll assembly. You reference the compiled output, not the source code. They’re designed for reusable .NET code, not front-end assets—sharing TS/JS/CSS via a class library would require extra work to copy those files into your web projects, which is far less straightforward.

• File & Language Support
  Shared projects natively handle any file type (TS, JS, CSS, etc.) because they’re just embedding source files into your web projects. Class libraries in VS2015 are focused on .NET languages; while you can add front-end files to them, they won’t automatically be included in your web project’s build process without custom configuration.

• Build Output Behavior
  A shared project has no build output of its own—all its files are compiled as part of the referencing web project. A class library builds its own DLL, which your web project links against. For front-end code, this is a downside because you need the source (or bundled) files in your web project, not a .NET DLL.

That error pops up because TypeScript’s rootDir setting expects all your source files to live under the specified directory, but your import is jumping outside Project 1’s root to access Project 2’s files. Here’s how to fix it:

1. Set Up TypeScript Path Aliases #

First, configure tsconfig.json to map your shared project’s path to a clean alias, so you don’t have to use messy relative paths:

{
  "compilerOptions": {
    "baseUrl": ".", // Sets the base directory for resolving paths
    "paths": {
      "@shared/*": ["../2/*"] // Maps the @shared alias to your shared project's root
    }
  }
}

Now you can import your types neatly:

import { Types } from '@shared/Constants/Types';

This tells TypeScript exactly where to find the file without violating the rootDir rule.

2. Update Webpack to Recognize the Alias #

Webpack needs to know about this alias too, so add it to your webpack.config.js:

const path = require('path');

module.exports = {
  // ... your existing webpack configuration
  resolve: {
    alias: {
      '@shared': path.resolve(__dirname, '../2/') // Match the path from your tsconfig
    }
  }
};

This ensures Webpack can resolve the alias when bundling your code.

3. Double-Check Your rootDir Setting #

If you still run into issues, verify your tsconfig.json’s rootDir is set correctly. If your two web projects are siblings sharing code, you could set rootDir to their parent directory (just note this might affect your output directory structure, so test it first).

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