安装
1 | curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh |
指令
1 | cargo new demo # 创建一个 demo 项目 |
1 | ├── Cargo.toml |
main.rs
1 | fn main() { |
Cargo.toml
1 | [package] |
类似于 package.json
1 | curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh |
1 | cargo new demo # 创建一个 demo 项目 |
1 | ├── Cargo.toml |
main.rs
1 | fn main() { |
Cargo.toml
1 | [package] |
类似于 package.json
官方文档:https://docs.npmjs.com/about-semantic-versioning
通过语义化版本控制(Semantic Versioning Rules),可以让包使用者知道包的版本改变的情况,以及对其他包版本依赖情况。
版本情况 | 阶段 | 规则 | 举例 |
---|---|---|---|
首次发布 | 全新产品 | 从 1.0.0 开始 | 1.0.0 |
向前兼容的 bug 修复 | 补丁版本 | 在第三个数字上增加 | 1.0.1 |
向前兼容的新版本 | 次要版本 | 增加第二个数字,并且第三个数字置零 | 1.1.0 |
不向前兼容的新版本 | 主要版本 | 增加第一个数字,将第二、第三个数字归零 | 2.0.0 |
在 package.json
文件里,通过定义 dependencies
来表明包的依赖情况如:
1 | "dependencies": { |
规则如下:
^
表示不增加从左到右第一个非0的部分的,所有其他部分不减少的版本如:
^2.2.1
: 2.2.2
2.2.3
2.3.1
等^0.2.1
: 0.2.2
0.2.3
等~
表示包含相同次要版本和主要版本情况下,相等或者更好的版本:
~2.2.0
: 2.2.0
2.2.1
2.2.2
等通过 >
<
=
>=
<=
或者 -
来表示范围( -
左右有一个空格):
>2.1
: 2.1.1
2.2
3.0.0
等1.0.0 - 1.2.0
: 1.0.0
1.0.1
1.1.1
1.2.0
等>= 2.1 <=3.1
: 2.1.0
3.0.1
3.1.0
等包含预览版本,如带有 alpha
和 beta
等标志的版本如:
1.0.0-rc.1
预览版本之间有特殊匹配规则,如 >0.5.0-rc.1
能够匹配 >0.5.0-rc.2
,能够匹配 1.0.0
2.1.0
等,但是不能匹配 1.0.0-rc.1
。
也就是说,范围匹配在带有特殊标志的版本号之间是不适用的,仅仅适用于标志后面的版本号。主要出于以下原因:
(1) 预览版本有很多问题,并且可能很快迭代,换句话说可能不稳定,所以不能作为一个常规版本让大家使用,所以从语义化版本控制中特殊化处理。
(2) 假设使用预览版本的人能够接受当前版本的风险如 0.5.0-rc.1
但这不能证明他们能接受 1.0.0-rc.1
的风险,所以不让其满足范围匹配。
用 ||
表示“或者”,如:
^2 <2.2 || > 2.3
: 2.0.0
3.8.0
4.14.1
等更详细的规则: https://semver.org/
npm 语义化版本控制器: https://github.com/npm/node-semver
官方文档:https://docs.npmjs.com/about-packages-and-modules
package,包,它是一个由 package.json
描述的文件或者目录,一个包必须包含一个 package.json
文件。
package.json
文件描述的程序。1
的压缩包2
的URL<name>@<version>
且它包含一个 3
<name>@<tag>
指向 4
latest
标签的 <name>
且它满足 5
1
而 git 的 url 满足以下情况:
git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
commit-ish
可以是任何标志,比如分支名、hash值这些可以作为git checkout
参数的内容,默认的 commit-ish
是 master
module,模块,它是 node_modules
里面的任何可以被 Node.js
的 require()
函数所加载的文件或者目录。形式如下:
package.json
文件的文件夹JavaScript
文件由于模块不一定包含一个 package.json
文件,而包一定包含,所以模块不一定是包,但包含 package.json
文件的模块也是一个包。
在 Node.js
的程序上下文中,模块也可以理解为一个从文件里被加载的事物,比如
1 | var req = require('request'); |
那么我们就会说 req
是 request
模块的引用。
一直在使用npm,但是关于npm究竟是什么,其工作原理等,还不是很了解,于是研究了一下 npm官方文档,准备系统学习一下npm,作为一个开始,先实践一下如何发布npm包。
Scope,我想把它翻译为空间,比如:
1 | npm i @vue/compiler-dom |
它的作用有两个:
为了有一个Scope,我们需要 注册 一个npm账号,以及 创建 一个npm组织。
package.json
文件可以手动创建该文件,也可以使用进入到你的包的根目录下,使用 npm init
进行创建。
module
1 | exports.printMsg = function() { |
1 | npm login |
输入账号、密码和OTP后就可以登录了
1 | npm publish |
这样就可以发布了
作为一名刚入门的前端,我深深意识到我能力的不足,无论是从技术的广度还是深度,我都是刚刚入门。这就是为什么我要搭建一个简单的博客,它的作用就是做笔记。我喜欢系统地学习知识,而不是碎片化的,系统地就代表着需要把内容全部仔仔细细地学一遍,然后归纳总结,然后复习,而做笔记就是复习的基础。
我希望这些小小的Blog能够成为我去构建我知识体系的砖块,一点一点建立属于我自己的技术大厦。
当然我也希望我能够输出一些高质量的总结,这些总结会分享到别的地方,比如一些技术文章社区,但大部分的Blog都只会作为笔记,然后悄悄地发布到在这上面.
我是一个宏观上很佛系的00后,读书的时候一般认真,读完高中进了一个中等偏上的大学,大学期间大部分时间都在玩,但是幸运的是加入了工作室,于是才学到了一点点前端的知识,而侥幸加入了字节跳动。
为什么说尝试改变自己呢?从21年的8月23日入职到现在,已经六个月了,除了在公司由于工作带来的学习以外,我没有进行过任何学习,下班只想打打游戏然后睡觉,周末也是。
这样的生活状态会让我慢性死亡,用不了多久,我便会变成一个麻木的人,不想思考,每天做着一样的事情,然后脑力、技术慢慢被迅速发展的前端行业所淘汰,最后剩下的,就是一个油腻,无用且麻木的中年男人。
所以我想改变自己,我想得到更多前端的知识,成为一个有用的人。
我希望我在有时间的时候,不是马上进入游戏世界,而是马上开始学习前端知识。大概的模式就是我会选择前端一门我没接触过的技术,系统地学习它,并且产出很多小Blog,这些Blog的形式就是笔记。
这个博客的搭建是使用的Hexo,它会把markdown解析成静态的html文件,而markdown正好也是做笔记的最佳工具。
从技术实现上讲,新的模式是:用Git管理我的笔记,然后当我push新的笔记时,Vercel又会重新帮我编译部署。
从学习过程上讲,新的模式是:系统学习,输出很多笔记Blog,然后将其整理为一篇有意义的文章。
三个好处:
加油吧!少年!