就在 2022 年圣诞节前夕，我们终于满足了 Hugh Parsonage 在 2018 年提出的编织请求（谢谢，Hugh）。也就是说，删除knitr中的stringr依赖项。最初的动机是为了加快安装knitr的速度，因为stringr依赖于stringi ，这是一个相对较重的依赖关系，可能需要相当长的时间来编译。这种动机不再那么强烈，因为以后安装stringi的预构建二进制文件变得更加容易（例如，通过 Posit 包管理器）。
不管怎样，如果可能的话，我总是赞成减少依赖，尤其是对于广泛使用的基础设施包。去年，当我看到Deepayan在 base R 中使用knitr在 R 帮助页面上运行示例和演示时，我有点担心knitr对这项任务来说可能太重了。
事实证明， knitr对stringr的依赖并不是太紧。这些函数大多可以直接替换为基本 R 函数，如gsub() 、 substr() 、 gregexpr()和regmatches() ，所以我们已经做到了。
随着stringr 的消失，这意味着knitr也删除了七个间接依赖项（请参见下面的依赖关系图）。只剩下四个硬依赖。对higher的依赖也可以被移除，因为它仅用于 Rnw 文档中的语法高亮显示，但它非常轻量级，我不确定是否值得打扰 Rnw 用户并要求他们显式安装higher （可能不值得） .
knitr (<= v1.41) |> evaluate |> highr |> stringr |> cli |> glue |> lifecycle |> magrittr |> rlang |> stringi |> vctrs |> yaml |> xfun
knitr (> v1.41) |> evaluate |> highr |> yaml |> xfun
现在留给我们弄清楚的一件事是这是否会对性能产生很大影响。我觉得影响应该是微不足道的，因为编织中最耗时的部分通常是评估代码块，而不是解析文档。无论如何，接下来我们将进行基准测试，并相应地用结果更新这篇文章。同时，请随时亲自尝试一下，如果您发现任何性能问题，请告诉我们：
install.packages('knitr', repos = c( yihui = 'https://yihui.r-universe.dev', CRAN = 'https://cloud.r-project.org' ))
谢谢！