tsc编译错误'error TS1008: Unexpected token; 'module, class, interface, enum, import or statement' expect

给遗留的JS代码写了类型声明，兴冲冲地跑去编译，结果报了一堆错，人都傻了：

H:\project\dataStore.d.ts(1,9): error TS1005: ';' expected.
H:\project\dataStore.d.ts(1,19): error TS1005: ';' expected.
H:\project\dataStore.d.ts(1,25): error TS1005: ';' expected.
H:\project\dataStore.d.ts(2,5): error TS1008: Unexpected token; 'statement' expected.
H:\project\dataStore.d.ts(19,1): error TS1008: Unexpected token; 'module, class, interface, enum, import or statement' expected.

当然了，不是直接编译声明文件，是在main里导入，然后编译main。这个声明文件是这样的：

declare namespace NSApp {
    class DataStore {
        private data: IData;
        constructor();
        add(key: string, val: any): void;
        get(key: string): any;
        getAll(): IData;
        remove(key: string): void;
    }
    interface IData {
        [email: string]: any;
    }
}

看起来是不是没什么问题？事实上，就是没问题。因为换了一个项目，同样的代码编译成功了。实在是神秘。

我一开始怀疑是tsc的调用出了问题。去全局库里查看tsc脚本的内容：

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe"  "%~dp0\node_modules\typescript\bin\tsc" %*
) ELSE (
  @SETLOCAL
  @SET PATHEXT=%PATHEXT:;.JS;=;%
  node  "%~dp0\node_modules\typescript\bin\tsc" %*
)

可以看出，tsc在被调用的时候确实指向的就是全局库。如果不放心，还可以顺便看看Linux环境下的shell脚本确认一下，因为理论上库的表现应该是一致的；毕竟，按照信息隐藏的观点，操作系统是需要被隐藏的实现细节：

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac

if [ -x "$basedir/node" ]; then
  "$basedir/node"  "$basedir/node_modules/typescript/bin/tsc" "$@"
  ret=$?
else 
  node  "$basedir/node_modules/typescript/bin/tsc" "$@"
  ret=$?
fi
exit $ret

而且，如果在npm的全局库里直接调用tsc，是可以编译的（同时也进一步说明了代码真的没问题）。那么，问题就不在npm上了。事实上，我在查TypeScript的issue的时候，看到了微软工程师的一句评论：

 

然后在查看tsc的版本的时候，我注意到了一个细节：

 

 

 

然而事实上我安装的typescript是最新版的3.5.3。这是咋回事，版本变了？

然后我去查了一下这个版本。官网上最早的文档是1.1的……不过在1.5版本的文档里提到：

 

namespace keyword

TypeScript used the module keyword to define both “internal modules” and “external modules”; this has been a bit of confusion for developers new to TypeScript. “Internal modules” are closer to what most people would call a namespace; likewise, “external modules” in JS speak really just are modules now.

Note: Previous syntax defining internal modules are still supported.

Before:

module Math {
 export function add(x, y) { ... }
}

After:

namespace Math {
 export function add(x, y) { ... }
}

let and const support

ES6 let and const declarations are now supported when targeting ES3 and ES5.

 

 

事实上，直到1.5版本，才引入了namespace关键字和let、const关键字的支持，而这个1.0.3.0的版本显然是不支持的，所以编译不通过就解释得通了。

找到了编译不通过的原因，现在的问题是，为什么会有这个版本呢？查了一下，发现C盘里有这样一个文件夹：C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0。然后在系统变量的Path里也有这一条：

 

 

这就说得通了。我们都知道，对于Windows的环境变量来说，上面的会覆盖下面的，所以这个1.0.3.0版本覆盖了通过npm安装的3.5.3版本；而这个Microsoft SDKs文件夹是安装Visual Studio的时候（被）安装的。

以下是考据环节，不感兴趣的读者可以略过：

我当时装的是VS 2013，正好对应TS的1.0版本；因为TS1.0正式发行是在2014年4月3日前后（见参考资料，因为微软官网上关于这个的页面已经404了），正好对应当时的’Visual Studio 2013 and Visual Studio Web Express 2013 Spring Update’，从这个版本之后的VS里都有TS了。

而我装的是VS Community 2013 update 4，时间是2014年12月11日：

 

 自然也是有的。应该就在Web Developer Tools里：

 

 事实上，我换了另一台电脑，上面的TypeScript版本就不一样了，然后又换了一台没装过VS的电脑，里面就没有这个文件夹了，验证了这个猜想。也就是说，两年前为了学习C语言装的VS，在两年后坑了我……

 

找到了问题，那么就是解决方案了。目前我发现的方案有两种：

第一种，从源头上解决，删除这个文件夹（没影响的），或者从环境变量里删掉这一条。如果实在不放心，就调整一下环境变量的顺序，让npm的全局仓库在它上面，把它覆盖掉。

第二种，我们都知道Node会优先使用项目库，然后再使用全局库，所以我们可以把这个项目初始化成一个Node项目（如果之前不是Node项目），然后npm install typescript，安装一个项目内部的typescript依赖，这时候tsc就会优先寻找项目内部的typescript依赖，这样也能解决。

为什么跟Node有关？可以看看之前的tsc脚本，里面明确写了是通过Node调用的：

node  "%~dp0\node_modules\typescript\bin\tsc" %*

 

 

转： https://blog.csdn.net/HermitSun/article/details/96478912