提几个建议

[xingluo233]

1. 建议使用unbuild打包后，这个js提供给浏览器环境使用，再用tsc编译一遍，给nodejs用，现在这样子，报错后，会把整个index.mjs的内容都输出到终端

2. 建议改改各个方法的调用方式

hmac(sha1, 160, 80)(key)(m).to(HEX)

这种多个括号连着的调用，不方便ide提示

3. 建议有个默认导出

[xingluo233]

0.0.6版本，各方法都没有提示

[RSoraM]

0.0.6版本，各方法都没有提示

你好，代码提示的问题在我的IDE上没有出现。虽然不太可能，但昨天我发包的时候碰到了npm在维护，服务恢复后我上传了0.0.6，不清楚是设置的问题还是npm的问题，或许卸载再重新安装会有帮助。你也可以检查一下 node_modules 里有没有对应的 d.ts

[RSoraM]

1. 建议使用unbuild打包后，这个js提供给浏览器环境使用，再用tsc编译一遍，给nodejs用，现在这样子，报错后，会把整个index.mjs的内容都输出到终端
2. 建议改改各个方法的调用方式

hmac(sha1, 160, 80)(key)(m).to(HEX)

这种多个括号连着的调用，不方便ide提示

3. 建议有个默认导出

1. 打包的问题，我没有研究过当中的区别，对我来说 It just work，所以我需要研究过后再给你答复。

2. 我不太清楚你说的 IDE 提示的问题，能详细说说是怎么不方便吗？

这种几个括号的调用方式是为了更高级的加密方案设计的...像 ecies 需要一个 KeyHash 来签名，为了同时支持 HMAC 和 KMAC，我需要他们在某个阶段返回相同的类型。所以按照 mac(config)(key)(m) 的感觉来设计接口，至于为什么不是 mac(config)(key, m) 我不记得了...

3. 对我来说默认导出的意义一直都不是很大，因为默认导出在我看来就是全部导入，import * as mima from 'mima-kit' 这个和默认导出也没什么区别...反而部份导入的写法能保证摇树，所以我的习惯也是写部份导入。你能说下为什么你需要一个默认导出，以及默认导出什么吗？因为 mima-kit 的东西有点杂...

[xingluo233]

这是第一点提到的问题，报错后，整个index.mjs的内容被输出到了终端，还有就是这一整个js，如果用户从ide跳转到源码查看的话，不是太方便

第二点主要是只有括号，ide无法知道这里面是什么参数，无法给用户提示，其次是这样太小众了吧，我还是第一次见这样调用的

第三点没啥问题了

[RSoraM]

这是第一点提到的问题，报错后，整个index.mjs的内容被输出到了终端，还有就是这一整个js，如果用户从ide跳转到源码查看的话，不是太方便

第二点主要是只有括号，ide无法知道这里面是什么参数，无法给用户提示，其次是这样太小众了吧，我还是第一次见这样调用的

第三点没啥问题了

关于第一个问题，我想我明白你的意思了，但很抱歉我无法在我的终端和浏览器复现这个问题，这似乎是IDE在报错时引用打包的文件导致的。unbuild 打包的文件，除了接口文件都经过了 minify，通过npm安装只会拿到打包后的文件，所以对开发者来说顶多就是从ide跳转到d.ts看下接口定义。看mjs和cjs找源码问题是很费劲的，如果你发现函数的行为不在预期内，你可以从仓库的源码中找问题或者报个issue

关于第二个问题，其实js里闭包返回函数还是挺常见的，如果你觉得这样很奇怪的话，这样写会不会没这么奇怪？

const k = UTF8('key')
const m = UTF8('message')

// HMAC-SM3
const mac = hmac(sm3)
const tag = mac(k)(m)

// KMAC-128-256
const mac = kmac128(256, UTF8('custom tag'))
const tag = mac(k)(m)

// 或许我可以将接口改为
const tag = mac(k, m)

而且从我的观察来看，大部分时候用散列函数都不会输入太大的内容。所以 mima-kit 的散列函数都没有做以前那种 update-digest 模式，而是选择做简单的IO。如果是简单IO的话，我在config后返回只有一个digest的对象和返回一个函数，似乎也没这么大区别...

// update-digest
function hmac(...){
  return {
    update:(M:Uint8Array)=> ...,
    digest:()=> U8,
  }
}

// IO
function hmac(...){
  return {
    digest:(K:Uint8Array, M:Uint8Array)=> U8,
  }
}
// 真没多大区别...
function hmac(...){
  return (K:Uint8Array, M:Uint8Array)=> U8
}

关于 IDE 提示的问题，我的 IDE(vscode) 在鼠标hover和输入括号时是有jsdoc提示的，但不是全部都有，因为jsdoc是一个很庞大的工作量。

我留意到源码中 KeyHash 接口没有写 jsdoc，这可能是导致ide没有hmac后续提示的原因。我已在新的 commit 解决这一问题，在下一个版本推送。

[xingluo233]

这是第一点提到的问题，报错后，整个index.mjs的内容被输出到了终端，还有就是这一整个js，如果用户从ide跳转到源码查看的话，不是太方便

第二点主要是只有括号，ide无法知道这里面是什么参数，无法给用户提示，其次是这样太小众了吧，我还是第一次见这样调用的

第三点没啥问题了

关于第一个问题，我想我明白你的意思了，但很抱歉我无法在我的终端和浏览器复现这个问题，这似乎是IDE在报错时引用打包的文件导致的。unbuild 打包的文件，除了接口文件都经过了 minify，通过npm安装只会拿到打包后的文件，所以对开发者来说顶多就是从ide跳转到d.ts看下接口定义。看mjs和cjs找源码问题是很费劲的，如果你发现函数的行为不在预期内，你可以从仓库的源码中找问题或者报个issue

关于第二个问题，其实js里闭包返回函数还是挺常见的，如果你觉得这样很奇怪的话，这样写会不会没这么奇怪？

const k = UTF8('key')
const m = UTF8('message')

// HMAC-SM3
const mac = hmac(sm3)
const tag = mac(k)(m)

// KMAC-128-256
const mac = kmac128(256, UTF8('custom tag'))
const tag = mac(k)(m)

// 或许我可以将接口改为
const tag = mac(k, m)

而且从我的观察来看，大部分时候用散列函数都不会输入太大的内容。所以 mima-kit 的散列函数都没有做以前那种 update-digest 模式，而是选择做简单的IO。如果是简单IO的话，我在config后返回只有一个digest的对象和返回一个函数，似乎也没这么大区别...

// update-digest
function hmac(...){
  return {
    update:(M:Uint8Array)=> ...,
    digest:()=> U8,
  }
}

// IO
function hmac(...){
  return {
    digest:(K:Uint8Array, M:Uint8Array)=> U8,
  }
}
// 真没多大区别...
function hmac(...){
  return (K:Uint8Array, M:Uint8Array)=> U8
}

关于 IDE 提示的问题，我的 IDE(vscode) 在鼠标hover和输入括号时是有jsdoc提示的，但不是全部都有，因为jsdoc是一个很庞大的工作量。

我留意到源码中 KeyHash 接口没有写 jsdoc，这可能是导致ide没有hmac后续提示的原因。我已在新的 commit 解决这一问题，在下一个版本推送。

第一点的问题，只要用tsc编译一遍就可以解决了吧，再把packge.json里的main改成index.js，把这些ts编译成的js上传到npm就行了吧。就比如说axios，同时上传了打包后的js和ts编译成的js，main是编译后的index.js，这样更适合在nodejs里使用。

第二点，我是没见过什么库会使用闭包的方式调用方法，我个人觉得mac(k, m)这样更好一点，因为m做为mac函数的参数后，就算没写jsdoc，ide也能知道函数有这个参数，用户也可以通过参数名来推测是做什么用的

[xingluo233]

@RSoraM 对了，我有一个疑惑，之所以要用unbuild打包，是为了可以在script标签里直接引入吧，但是0.0.6版本添加了一个依赖asn1js，unbuild不会把这个依赖一起打包进去，而是通过import或者require导入asn1js，这样子的话，就不能在src标签里使用了吧
如果不是为了这样的话，那应该没必要打包成单js吧

[RSoraM]

@RSoraM 对了，我有一个疑惑，之所以要用unbuild打包，是为了可以在script标签里直接引入吧，但是0.0.6版本添加了一个依赖asn1js，unbuild不会把这个依赖一起打包进去，而是通过import或者require导入asn1js，这样子的话，就不能在src标签里使用了吧

我用 unbuild 的原因没有那么复杂，我在一开始的回复中就说到

我没有研究过当中的区别，对我来说 It just work

js 混乱的历史造就了如今一大堆的 CI 工具，我并不关心这些工具的细节 webpack 的文档看多眼都想吐 。CI 很重要但比起 CI，我更关心接口的设计和代码的可读性和可维护性，其次是文档。所以，感谢你在 CI 方面的建议，因为我真的不知道这些怪东西。

我确实不知道依赖会让 script 标签无法直接引用的问题，但我对这个依赖是有意见的。因为我只在 pkcs 的一个老的签名方案里用到了很小的一部分，未来的某个版本里我会想办法移除这个依赖。

但现在 TurboSHAKE 和 K12 是我关注的内容。

[xingluo233]

@RSoraM tea和xtea加解密似乎有问题，加密结果和网上的工具加密的结果不一样，而且解密出来是数据并不是原来的数据

这个网站 tea的加密结果是706aeec1d4e33db8
这个网站 xtea的加密结果也不一样，都是64轮