背景
注意到这个事情,是因为今天在工作中发现了由此导致的一个构建问题。我在某个项目A上进行开发,该项目依赖了一个公共组件C。C是由其他同学负责维护,里面的JS源码、以及由 ES6 编译为 ES5 之后的部分文件名,是大写开头的(当然了,我个人是习惯于总是小写命名文件,用连字符处理长文件名情形),但是有个文件在创建的时候,用了小写开头的:pick.js,但是在引用的时候,是这样的:
1 | import * from './Picker.js'; |
由于我们所有的开发人员都是配 Mac,因此在开发环境中,并没能发现这个隐藏的错误。只是在 A 项目中,发现这个文件是找不到的(我们使用了 webpack 进行构建):
1 | Module not found: Error: Can't resolve './Picker' in 'some-file' |
最后,通过修改文件名,就解决了这个问题。
现状
| 操作系统 | 文件系统 | 是否大小写敏感 |
|---|---|---|
| Unix | 是 | |
| Linux | 是 | |
| MacOS | 日志式 HFS+ | 默认否 |
| Windows | FAT32 NTFS | 默认否 |
在 Is bash in OSX case-insensitive? 中有一个很好的回答:
HFS+ (the Mac filesystem) is usually configured to be case insensitive but case preserving. This means that the file system will consider
fooandFoOto be the same, but when you create a new file it will remember which letters where capitalized and which were not.To check whether a disk is case sensitive, run for example:
diskutil info disk0s2Look for the
Name:line. If it reads something likeMac OS Extended (Case-sensitive, Journaled)it means that it is case-sensitive. If it just readsMac OS Extended(without the Case-sensitive) then it is only case preserving but not case sensitive.
小结
要意识到不同操作系统之间是存在这些最基本的差异的。而文件命名,也最好要养成一个习惯,尽量只使用小写。