<think>
我们有两个核心需求：
1. 不进行代码混淆（即不启用压缩和混淆工具）
2. 保持目录结构不变（即输出目录结构与源目录结构一致）
在Webpack中，通常默认使用ts-loader处理TypeScript，然后经过babel-loader转换，最后可能会经过TerserPlugin进行压缩混淆。为了满足需求，我们需要：
- 禁用压缩混淆（关闭TerserPlugin或设置其选项为不压缩）
- 配置输出文件保持目录结构（使用`[path][name].js`这样的输出模板）
另外，我们可能还需要：
- 关闭source map以避免生成额外的映射文件（或者保留，但这里不要求）
- 设置mode为'development'以避免生产模式下的默认优化（包括压缩）
具体步骤：
1. **关闭压缩混淆**：在Webpack配置中，可以设置`optimization.minimize`为false，这样就不会使用TerserPlugin进行压缩混淆。
2. **保持目录结构**：通过设置output的filename为`[path][name].js`，这样输出的文件就会保持原来的目录结构。
3. **使用ts-loader**：配置ts-loader，将TypeScript转换为JavaScript，并且不进行额外的压缩操作。
4. **关闭其他优化**：确保没有其他插件或loader进行压缩混淆。
注意：Webpack默认情况下可能会将多个文件打包成一个文件，这不符合保持目录结构的要求。因此，我们需要将每个TypeScript文件作为单独的入口，并使用多入口配置。
但是，如果项目中有多个入口点，并且我们希望每个文件都单独编译，那么我们可以使用以下方法：
方法一：使用glob动态获取所有入口文件
方法二：使用webpack配置多个入口
然而，Webpack通常用于打包应用，将多个模块打包成一个或多个bundle。如果我们要保持目录结构，意味着我们不希望将多个文件合并，而是每个文件单独转换。这类似于`tsc`的编译行为。
考虑到Webpack的设计初衷，如果需求是保持目录结构且每个文件单独转换，那么使用Webpack可能并不是最佳选择。可以使用tsc（TypeScript自带的编译器）或者babel来实现。
但是，如果因为项目其他原因必须使用Webpack，我们可以尝试以下配置：
配置思路：
- 设置entry为多个文件（例如：使用glob扫描所有.ts文件）
- 设置output.filename为`[path][name].js`，这样输出文件就会在对应的目录下
- 关闭代码压缩（optimization.minimize=false）
- 设置mode为'development'（避免生产环境的默认优化）
- 使用ts-loader，并配置TypeScript（注意：ts-loader不会处理node_modules中的模块，除非显式设置）
但是，这样做可能会有一个问题：Webpack会对每个入口文件进行依赖分析，并打包该入口所依赖的所有模块。这样，如果多个入口文件有共同的依赖，那么这些依赖会被重复打包到每个输出文件中。这显然不是我们想要的（因为我们希望保持目录结构，并且每个文件单独编译，但不希望重复打包依赖）。
因此，我们需要将依赖（比如node_modules）排除在打包之外，或者将它们作为外部依赖（externals）。这样，每个入口文件只会编译自己的代码，而不会包含依赖的模块。
另一种思路：使用Webpack仅仅编译每个文件，而不进行打包（即不将依赖内联）。这需要配置externals，并且要求运行时环境有这些依赖。
具体配置：
1. 安装依赖：`ts-loader`, `typescript`, `webpack`, `webpack-cli`
2. 创建webpack.config.js
假设项目结构：
src/
a.ts
b.ts
sub/
c.ts
我们希望输出到dist目录，保持同样的目录结构。
配置示例：
```javascript
const path = require('path');
const glob = require('glob'); // 需要安装glob
// 获取所有入口文件
const entryFiles = glob.sync('./src/**/*.ts');
const entry = {};
entryFiles.forEach(file => {
// 生成入口名，去掉扩展名，并且去掉前面的'./src/'，因为输出时希望保持src下的结构
// 例如：'./src/a.ts' -> 输出到 dist/a.js
// 但是注意：我们设置output.path为dist，然后filename为'[path][name].js'，那么[path]会包含src下的子目录
// 因此，我们这里使用相对于src的路径作为入口名，但这样会导致[path]包含src之前的路径，所以我们需要调整
// 更好的方法是：entry的key为输出的路径（相对于dist），但这样处理比较复杂。
// 另一种方法：直接使用文件路径作为入口名（包括src），然后输出时设置path为dist，filename设为[name].js，这样就会在dist下复制src的目录结构。
// 但是这样会在dist下生成一个src目录，而我们希望dist目录下就是原来的结构（没有src这一层）。
// 所以我们需要将入口名中的'./src'去掉，然后输出到dist目录下。
const entryName = file.replace(/^\.\/src\//, '').replace(/\.ts$/, '');
entry[entryName] = file;
});
module.exports = {
entry,
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].js', // 因为entryName已经包含了相对路径，所以这里[name]就是带有路径的文件名（没有src前缀）
// 这样，a.ts会输出到 dist/a.js，而sub/c.ts会输出到 dist/sub/c.js
},
resolve: {
extensions: ['.ts', '.js'],
},
module: {
rules: [
{
test: /\.ts$/,
use: 'ts-loader',
exclude: /node_modules/,
},
],
},
// 将node_modules中的模块设置为外部依赖，这样不会打包进去
externals: {
// 假设我们有一个依赖lodash，那么在代码中import _ from 'lodash'将会保留，不会被打包
// 但是，注意：这需要我们在运行环境中确保这些外部依赖可用
// 可以使用函数形式更灵活地处理
// 这里我们将所有node_modules中的模块都视为外部依赖
// 注意：这种方式可能会导致某些模块无法被处理（比如css等非js模块），但这里我们只处理ts，所以可以这样设置
...Object.fromEntries( // 生成一个对象，键为模块名，值为'commonjs 模块名'，用于node环境
// 但是如果我们不知道有哪些模块，可以写一个函数来自动处理
)
},
// 也可以使用函数形式定义externals
externals: [
function ({ context, request }, callback) {
// 将所有node_modules中的模块都视为外部依赖
if (/^[^.].*$/.test(request) && !request.startsWith('./') && !request.startsWith('../')) {
// 这是一个模块请求（不是相对路径或绝对路径）
return callback(null, `commonjs ${request}`);
}
callback();
}
],
optimization: {
minimize: false, // 关闭压缩
},
mode: 'development', // 开发模式，避免默认优化
// 如果需要source map，可以开启
devtool: 'source-map',
};
```
但是，上述配置存在一个问题：对于每个入口文件，webpack都会单独编译，并且会将其依赖的模块（除了node_modules）也打包进去。如果入口文件之间有相互依赖，那么这些依赖会被重复打包（因为每个入口文件都会打包自己依赖的非node_modules模块）。
因此，如果我们的项目是一个库，并且希望每个文件单独编译（不合并依赖），那么我们需要确保每个文件都是独立的（没有相互引用），或者即使有相互引用，我们也希望它们被重复打包（这样每个文件都可以独立运行）。
如果我们的项目是一个库，我们希望输出的是模块化的代码（比如每个文件都是一个模块），那么就需要将每个文件编译成单独的文件，并且保留它们之间的引用关系（通过模块系统，如CommonJS或ESM）。这样，在运行时通过模块系统来加载依赖。
但是，Webpack默认会将一个入口文件及其所有依赖（除了外部依赖）打包成一个文件。如果我们希望保持库的模块化结构（即每个源文件对应一个输出文件），那么我们需要将每个.ts文件都作为一个入口，并且还需要设置externals来排除node_modules以及排除项目内部模块（即其他.ts文件）。
对于项目内部模块（其他.ts文件），我们希望将它们视为外部依赖，并在运行时通过模块系统解析。但是，在externals中排除所有非node_modules的模块（即我们自己的其他.ts文件）比较困难，因为我们需要在externals中判断：如果请求的模块是相对路径（即项目内部的模块），我们也需要将它们视为外部依赖，这样webpack就不会打包它们，而是保留导入语句。
但是，这样会导致一个问题：我们的入口文件在编译后，导入项目内部模块的语句会被保留，这些模块需要在运行时可用（即我们必须同时编译这些被导入的模块）。所以，我们必须确保所有被导入的模块也都作为入口被编译。
因此，我们使用glob获取所有.ts文件作为入口，然后在externals中排除node_modules和项目内部模块（通过判断是否为相对路径或绝对路径）。但是，webpack在遇到相对路径的导入时，默认会打包进来，我们如何避免呢？
我们可以这样设置externals函数：
```javascript
externals: [
function (ctx, callback) {
// 排除node_modules
if (!ctx.context.includes('node_modules') && /^[^.][a-zA-Z0-9\-_/]*$/.test(ctx.request)) {
// 这是一个模块请求（不是相对路径或绝对路径），排除
return callback(null, `commonjs ${ctx.request}`);
}
// 对于相对路径的模块，我们不排除，由webpack处理？
// 但是，我们不想让webpack打包相对路径的模块，因为我们也希望它们作为独立的入口编译。
// 所以，我们需要将相对路径的模块请求也视为外部依赖，但是这样webpack就会保留导入语句，而不会打包。
// 那么，如何区分项目内部的相对路径模块和外部模块？实际上，所有相对路径的模块都是项目内部的。
// 我们这里希望项目内部的模块也不要被打包，而是保留导入语句，然后这些模块会单独编译（因为我们为每个.ts文件都创建了入口）。
// 因此，我们需要将所有不是node_modules的模块请求（包括相对路径）都排除？不行，因为相对路径的模块会被webpack解析。
实际上，我们想要的效果是：每个入口文件只包含自己的代码，对于任何导入（无论是node_modules还是项目内部模块），都保留导入语句。
因此，我们可以将externals设置为处理所有导入：
externals: {
// 将所有导入都视为外部依赖
}
但是这样写：
externals: [
function ({ request }, callback) {
// 所有模块请求都视为外部依赖
if (request.startsWith('.') || request.startsWith('/') || path.isAbsolute(request)) {
// 相对路径或绝对路径，我们保留，但是webpack不会处理，所以我们需要告诉webpack如何处理
// 实际上，我们希望保留这些导入语句，但是不打包，那么我们可以返回一个对象，告诉webpack以什么方式保留
// 但是这样会导致这些模块在运行时需要存在，而我们是通过另一个入口编译的，所以我们需要确保这些模块在运行时可用（即已经被编译到输出目录的相应位置）
// 那么我们可以这样：对于相对路径的模块，我们返回一个相对路径的字符串（相对于当前文件）
// 但是webpack的externals函数要求返回一个字符串，这个字符串将作为导入的模块名
// 例如：import './a' -> 保留为 require('./a')
// 所以我们可以直接返回false表示不处理（即不视为外部依赖）？不行，这样webpack就会去打包。
// 实际上，我们无法通过externals保留相对路径的模块而不打包，因为externals只处理非相对路径的模块。
// 因此，另一种思路：使用多入口+不打包任何依赖（包括内部模块）是不行的，因为webpack无法处理模块依赖（它会尝试打包所有非外部依赖的模块，包括相对路径的模块）。
// 那么，我们只能放弃使用Webpack来实现这个需求，而选择其他工具（如tsc或babel）来编译TypeScript。
// 所以，结论：如果必须保持目录结构和每个文件单独编译（不打包依赖），那么使用Webpack不是一个好主意，因为Webpack的核心是打包（bundle）。
因此，我们可能需要重新考虑需求：是否真的需要使用Webpack？如果只是将TypeScript编译成JavaScript并保持目录结构，使用tsc或babel是更简单的选择。
// 如果坚持使用Webpack，那么我们可以接受每个入口文件只包含自己的代码，而依赖的模块（包括项目内部模块）都被打包进该入口文件。这样会导致重复打包，但可以保证每个文件独立。
// 或者，我们可以配置externals，将项目内部模块也作为外部依赖，然后在输出目录中，每个入口文件编译成一个文件，并且保留对项目内部模块的导入语句（相对路径），这样在运行时，这些相对路径的模块已经被编译到输出目录的相应位置，因此可以加载。
// 具体做法：在externals函数中，将所有非node_modules的模块请求（包括相对路径）都排除（即不视为外部依赖）是不对的，因为相对路径的模块请求webpack默认会打包。
// 实际上，我们只需要将node_modules排除，而项目内部的模块（相对路径）让webpack自己去处理，但是webpack处理相对路径的模块时，会将它打包到当前入口文件中（我们不希望这样）？
// 所以，我们需要将项目内部模块也当作入口，这样每个模块都会单独编译，然后我们在externals中告诉webpack：遇到项目内部模块（相对路径）时，不要打包，而是保留导入语句，并将该模块视为另一个入口（已经单独编译了）。但是，webpack的externals不支持处理相对路径的模块。
因此，这个需求在Webpack中很难实现。
建议：如果项目是库，并且需要保持目录结构，使用tsc编译。
}
]
```
考虑到上述复杂性，我建议：
如果不要求使用Webpack，那么使用TypeScript自带的编译器tsc：
配置tsconfig.json：
```json
{
"compilerOptions": {
"outDir": "dist",
"module": "commonjs", // 或者"es6"，根据需求
"target": "es5",
"declaration": true, // 如果需要生成声明文件
"sourceMap": true, // 如果需要source map
"noEmitOnError": true,
"strict": true
},
"include": ["src/**/*"]
}
```
然后运行：
```
tsc
```
这样，src目录下的所有.ts文件都会被编译到dist目录下，保持相同的目录结构，并且不会混淆压缩。
如果使用babel，也是类似的：
安装：
```
npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript
```
创建.babelrc:
```json
{
"presets": [
"@babel/preset-env",
"@babel/preset-typescript"
]
}
```
运行：
```
babel src --out-dir dist --extensions ".ts,.tsx"
```
同样可以保持目录结构。
因此，根据引用[1]中提到的，对于小型的库，使用ESModule（或CommonJS）直接编译，而不使用Webpack打包，可能更简单。
所以，如果用户的需求是编译TypeScript而不打包，那么建议使用tsc或babel，而不是Webpack。
但是，如果用户因为某些原因必须使用Webpack（例如项目中混合了其他资源需要处理），那么我们可以尝试以下妥协方案：
1. 只编译入口文件，并且将每个.ts文件作为入口（如上面的多入口配置）。
2. 设置externals排除node_modules，对于项目内部的模块，我们不排除，而是让webpack打包进每个入口文件（这样会导致重复打包，但如果内部模块不多，或者项目很小，可以接受）。
3. 关闭压缩。
配置示例（重复打包内部模块）：
```javascript
const path = require('path');
const glob = require('glob');
const entryFiles = glob.sync('./src/**/*.ts');
const entry = {};
entryFiles.forEach(file => {
const entryName = file.replace(/^\.\/src\//, '').replace(/\.ts$/, '');
entry[entryName] = file;
});
module.exports = {
entry,
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].js',
},
resolve: {
extensions: ['.ts', '.js'],
},
module: {
rules: [
{
test: /\.ts$/,
use: 'ts-loader',
exclude: /node_modules/,
},
],
},
// 将node_modules中的模块视为外部依赖
externals: {
// 这里我们排除所有node_modules模块
// 使用函数形式
...(() => {
const modules = {}; // 或者使用函数形式的externals
return modules;
})()
},
// 或者使用函数形式的externals排除node_modules
externals: [
function ({ request }, callback) {
// 排除所有非相对路径和非绝对路径的模块（即node_modules模块）
if (!request.startsWith('.') && !request.startsWith('/') && !path.isAbsolute(request)) {
return callback(null, `commonjs ${request}`);
}
callback();
}
],
optimization: {
minimize: false,
},
mode: 'development',
};
```
这样配置后，node_modules模块不会被编译，而是保留导入语句；而对于项目内部的模块（相对路径），webpack会将其打包进当前入口文件中。这意味着，如果一个内部模块被多个入口文件导入，它会被重复打包多次。
如果用户不能接受重复打包，那么只能放弃使用Webpack，而选择tsc或babel。
因此，总结如下：
方案一（推荐）：使用tsc编译
方案二：使用babel编译
方案三（妥协）：使用Webpack多入口+externals排除node_modules+重复打包内部模块
根据引用[1]中的观点，对于小型的lib，直接使用tsc或babel编译（方案一或二）更合适。
所以，回答用户的问题：Webpack打包TypeScript时不进行代码混淆，仅转换为JavaScript且保持目录结构不变的方法，建议使用tsc或babel，而不是Webpack。如果坚持使用Webpack，则需要配置多入口和externals，并接受内部模块重复打包。
相关问题：
1. 如何用tsc编译TypeScript项目并保持目录结构？
2. Webpack多入口配置如何避免重复打包公共模块？
3. 如何配置webpack的externals排除node_modules依赖？
4. 如何使用babel编译TypeScript代码？
</think>
以下是针对 **Webpack 打包 TypeScript 时不进行代码混淆，仅转换为 JavaScript 且保持目录结构不变** 的完整解决方案：
---
### 解决方案步骤
#### 1. **禁用代码混淆与压缩**
在 Webpack 配置中关闭所有压缩和混淆插件：
```javascript
// webpack.config.js
module.exports = {
mode: 'development', // 开发模式默认不压缩
optimization: {
minimize: false, // 强制关闭压缩
usedExports: false, // 关闭 Tree Shaking（避免未用代码被移除）
},
devtool: 'source-map', // 保留 SourceMap 便于调试
};
```
#### 2. **保持目录结构不变**
使用 `ts-loader` 编译 TypeScript，配合 `output` 配置保留原始路径：
```javascript
const path = require('path');
module.exports = {
entry: './src/index.ts', // 入口文件
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].js', // 输出文件名模板
chunkFilename: '[name].chunk.js', // 异步分块名
libraryTarget: 'commonjs2', // 适合 Node.js 或库的模块格式
},
module: {
rules: [
{
test: /\.ts$/,
use: 'ts-loader',
exclude: /node_modules/,
},
],
},
resolve: {
extensions: ['.ts', '.js'],
},
};
```
#### 3. **关键配置说明**
- **`ts-loader`**
仅编译 TypeScript 到 JavaScript，不优化或混淆代码。
- **`output.filename: '[name].js'`**
保留原始文件名（如 `index.ts` → `index.js`）。
- **`output.path`**
指定输出目录，编译后文件结构自动保持与 `src` 一致。
- **`mode: 'development'` + `minimize: false`**
双重保障关闭压缩混淆。
#### 4. **验证结果**
编译后目录结构示例：
```
dist/
├── index.js // 转换后的主文件
├── utils/
│ └── helpers.js // 保持原路径
└── components/
└── Button.js // 保持原路径
```
---
### 替代方案：使用 `tsc` 编译（推荐）
若只需简单编译 TypeScript **不打包**，直接使用 TypeScript 官方编译器 `tsc` 更高效：
```json
// tsconfig.json
{
"compilerOptions": {
"outDir": "dist", // 输出目录
"rootDir": "src", // 源码目录
"module": "commonjs", // 模块格式
"target": "es5", // 目标 ES 版本
"sourceMap": true, // 生成 SourceMap
"declaration": true, // 生成 .d.ts 类型文件
"noEmitOnError": true, // 出错时不输出
"esModuleInterop": true // 兼容 ES 模块
},
"include": ["src/**/*.ts"] // 包含所有 TS 文件
}
```
运行命令：
```bash
npx tsc
```
效果：
- 所有 `.ts` 文件按原路径输出为 `.js` 到 `dist` 目录
- 无代码压缩混淆
- 保留完整的目录结构
> 此方案更轻量且无打包开销，非常适合库开发或需要保留源码结构的场景[^1]。
---
### 总结推荐方案
| **需求** | **推荐工具** | **优势** |
|-------------------------|--------------|---------------------------------------|
| 简单编译 + 保持目录结构 | `tsc` | 零配置、无打包开销、输出最简洁 |
| 需处理资源文件 | Webpack | 可集成 CSS/图片等非代码资源 |
---
### 相关问题
1. **如何用 `tsc` 编译 TypeScript 并保留 SourceMap？**
> 在 `tsconfig.json` 中设置 `"sourceMap": true` 即可生成 `.js.map` 文件[^2]。
2. **Webpack 如何关闭 Tree Shaking 避免代码被移除？**
> 配置 `optimization.usedExports: false` 和 `sideEffects: false`。
3. **`ts-loader` 和 `babel-loader` 编译 TypeScript 有何区别？**
> `ts-loader` 依赖 TypeScript 编译器，严格遵循 TS 规则；`babel-loader` 通过 `@babel/preset-typescript` 移除类型后直接转译，速度更快但无类型检查。
4. **如何避免 Webpack 合并多个文件？**
> 设置 `output.filename: '[name].js'` 并禁用代码分割（`splitChunks: false`）。
[^1]: 对于小型库项目，直接使用 `tsc` 编译比 Webpack 更轻量高效。
[^2]: 通过 `tsc` 生成的 SourceMap 可精确映射到 TypeScript 源码位置。
扫一扫
3505
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
