TypeScript

开启 Ts language server log

image.png

确认是否使用本地 ts server

image.png

TypeScript Plugin

目前 ts 的 plugin 只可用于在开发期间，配合 lsp 进行提示类生效，无法进入编译期所以，可以实现的内容有限。
见如下讨论：
https://github.com/microsoft/TypeScript/issues/16607
所以 ts plugin 其实只是 lsp，适合用于处理编译期已解决，但开发期间提示缺乏的场景：
https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

Ts 支持 CSS-Module 推导

通过上述的 ts plugin，实现 vscode 的类型推导。表现形式为：
image.png
但由于上述提到的局限性，首先是仅开发环境的，不能保证开发环境正常，编译期也正常。其次 ，编译期可以通过 webpack/rollup 实现很多 全局变量注入，样式提升 等效果，这些在开发环境中由于资源方不定，信息不全，不能实现正常的推导。

named export

由于 named export 本身是最终生成文件的特性，typescript 的编译通过是需要类型层的支持的，所以会出现，即使 name export 功能支持，但类型出错的情况。最简单的方式 ，抛弃类型的check，一切以开发环境来保障。其实使用 babel 进行 ts 文件编译就是直接的类型擦除。所以对于 样式的 named export，只要在 postcss 中实现即可使用。
或者在 开发中添加文件的 .d.ts 辅助类型生成，次简单方式，全局declare 中直接加：

  1. declare module '*.less' {
  2.   const classes: { readonly [key: string]: string };
  3.   export const fontSize: string;
  4.   export default classes;
  5. }

以及最麻烦的方式，为单个 less 文件添加 .d.ts。可惜 father 中会过滤 .d.ts 文件，所以无法实现。
https://github.com/umijs/father/issues/227
https://github.com/umijs/father/issues/227#issuecomment-720928000

FQ
为什么需要 declare：
为了通过类型检查
https://github.com/mrmckeb/typescript-plugin-css-modules/issues/11

TODO
按需引入，类似基于样式导出的tree-shaking
https://github.com/mrmckeb/typescript-plugin-css-modules/issues/129

Less

～

应该是在不存在 node_modules 自动寻址时，用于标识 替换为 node_modules 相对路径，的 alias 占位，被 postcss 沿用：
image.png
由于 less 中是不支持 js 语法的，所以 node_modules 相关的寻地址逻辑也是不支持的，所以需要额外的插件提供地址路径替换，所以无论是 webpack 中的 alias 还是 antd/lib 之类的 在 less 中的引入，都需要 ～ 前缀，来标识，需要经过额外的寻址处理。
father中有一段 rollup 配置是处理这类问题的：
image.png
可以看到只进行了 ～ 处理 node_modules，是不支持 alias 相关内容的。如果需要支持 alias，需要添加更多解析。

named export

由于 named export 是 esmodule 的内容，所以需要额外支持，webpack 环境中 css-loader 是支持的：
https://github.com/webpack-contrib/css-loader/issues/1029

  1. import { fontSize } from '../style/themes.less';

但是 rollup 中使用 rollup-plugin-postcss 进行相关支持，配置不相同。father中不支持传入该配置。
错误提示：
image.png
添加类型支持（勉强可用）：

  1. declare module '*.less' {
  2.   const classes: { readonly [key: string]: string };
  3.   export const fontSize: string;
  4.   export default classes;
  5. }

添加配置：
image.png
编译后成功：
image.png

全局变量共享&提升

通过 该loder，可以将某些变量在各文件中共享，也就同时获得了提升的效果
https://github.com/yenshih/style-resources-loader

额外：
CSS-Module 底层支持库 postcss-modules
支持对 className str 进行转化

Name Type Description
‘camelCase’ {String} Class names will be camelized, the original class name will not to be removed from the locals
‘camelCaseOnly’ {String} Class names will be camelized, the original class name will be removed from the locals
‘dashes’ {String} Only dashes in class names will be camelized
‘dashesOnly’ {String} Dashes in class names will be camelized, the original class name will be removed from the locals

yarn

本地包调试：yarn link

yarn link 会遇到依赖异常的问题，特别是一些开发环境使用包，如 yarn link 使用本地build 的 father-build，由于 father-build 执行过程 需要调用 typescript，所以会直接从本地 father-build 文件夹的 node_modules 中读取。
但是从 npm 中下载的包，是不自带 node_modules 内容的，install 后，只要 node_modules 的依赖内容不是大版本差异，都会尽量做依赖提升，所以存在外部使用的 依赖版本，大于 npm 包中需要版本的情况。
所以 yarn link 链接的本地 build 包，使用的是严格符合自己 package.json 的版本（本地 father-build 文件夹的 node_modules），会与 npm 安装的方式，存在依赖差异，导致调试出现问题。

也可以通过 resolution 指定依赖版本，进行替换，需要验证：

resolutions 解决 node_modules 指定问题

https://mp.weixin.qq.com/s/P5bBm5ogZHKtYgt8ttE0Fg
假如你的项目依赖了foo,foo依赖了bar@^1.0.0。假设bar现在有两个版本1.0.0和1.1.0。很不幸，bar在发布1.1.0的时候没有做好向后兼容。导致foo和bar@1.1.0不能搭配使用。如果你可以等：

  • 要么等foo把依赖bar锁成1.0.0并重新发版
  • 要么等bar修复兼容问题后重新发版

那如果你等不了呢，你已知foo和bar@1.0.0可以正常工作。如果你能锁住foo对bar的依赖就好了，但是这定义在foo的 packge.json 里，你总不能去改 node_modules/foo/package.json 吧？这不合适。resolutions[1]可以解决你的问题，只要在你自己项目的 package.json 里定义：

  1. "resolutions": {
  2.   "foo/bar": "1.0.0"
  3. }

这里的 key”foo/bar”表示foo的直接依赖bar，把版本区间重写成1.0.0。如果foo不是直接依赖的bar（foo -> … -> bar），我还需要把中间的链路都捋清楚吗？不用那么麻烦！

  1. "resolutions": {
  2.   "foo/**/bar": "1.0.0"
  3. }

如果你的项目里有很多依赖直接/间接的依赖了bar，每个定义的版本区间可能有差别，你知道某个版本可以让他们都能正常工作，而不用安装多个版本。也可以不用声明前缀部分，只写包名bar。这样不管是哪里依赖到了bar都会指向你声明的哪个版本。