在这里记录下nodejs各种小细节

ch3 Operating system and command-line integration

1. 吐槽

其实我们的nodejs并不是那么的跨平台
包括windows下的fs.filewatch触发两次，node-sass在windows下安装超级困难
某些包因为有node-gyp编译过程，导致在一个平台安装后在其他平台不能用
node-gyp是一个将c++代码编译成可供nodejs调用的二进制文件的node包
在linux下会使用gcc编译，windows下则是visual c++

2. 一些与runtime env有关的flag

• process.arch: 三个值：’arm’, ‘ia32’, or ‘x64’，代表32位/64位/arm系统结构
• process.memoryUsage(): 内存使用
• process.argv： 程序运行时传入的命令行参数
• process.cwd()： 程序运行时的目录
• process.env： 程序运行时的环境变量
• process.nextTick(callback[, arg][, …])： 将callback回调丢进Node下一个tick执行
• process.pid： 程序运行时的进程id
  更多属性查看

3. 结束程序

一般来说我们的程序是用户终止or执行完毕之后自动结束
那我们想精确控制程序结束时机该怎么办呢
答案在 process.exit(arg) 这个函数上
其中arg - 0 : 正常退出，arg - 1 : 带有错误退出
arg由程序编写者指定
more code meanings

4. 进程间通信

如果对进程及进程间通信感到陌生，建议先google补充基础知识

先看一个例子：

1
2
3
4
5

process.stdin.resume(); // 让程序监听 stdin标准输入，使其不会自动停止运行，直到用户按下 ctrl+c
process.on('SIGHUP', () => { //监听 SIGHUP事件
    console.log('Reloading configuration...');
});
console.log('PID:', process.pid);

nodejs对进程间的通信也描述成事件的形式
process本身也是一个EventEmitter对象
假设该程序的运行时的进程是：9999
在 unix like系统下，命令行运行kill -HUP 9999就可以向node进程发送SIGHUP事件
当然我们也可以写在代码里：

1

process.kill(9999, 'SIGHUP')

不过windows下SIGHUP不能用代码而只能用cmd发送，也算是与我之前吐槽向呼应了把

tips: kill [sign] [pid] 并不是指这个进程将会被killed，而仅仅是发送signal给进程

在这里记录下nodejs各种小细节

ch2 Standard I/O

首先讲一下什么叫做Standard I/O——标准输入输出流

Standard streams
Standard streams come in three flavors: stdin, stdout, and stderr. In Unix terminals,
these are referred to with numbers. 0 is used for standard input, 1 is standard output,
and 2 is standard error.
The same applies to Windows: running a program from the command prompt and add-
ing 2> errors-file.log will send the error messages to errors-file.log , just
like Unix.

标准流
标准流有三种类型 stdin,stdout,stderr,在类unix终端中，被引用为数字
0 - 标准输入
1 - 标准输入
2 - 标准错误
这也同样被运用在windows中:在命令行运行一个程序并在最后加上 2>err.log
将会把错误信息发送至err.log文件下（当然unix like系统同样如此）

那么这玩意有什么用呢?

nodejs提供了三个对象process.stdin, process.stdout, process.stderr
可以轻松的获取到标准输入输出

example:

1
2
3
4
5
6
7
8
9
10

// std.js
'use strict'
process.stdin.resume() //告诉node开始接收标准输入
process.stdin.setEncoding('utf-8')
process.stdin.on('data', (data) => {
  process.stdout.write(data.toUpperCase()); // 流的读取都是分段的
})

run with:

1

cat file.txt | node std.js | grep FOO

利用unix管道，可以将流pipe进node程序，node程序将读入的文本转成大写，再pipe出去
流会被下一个程序接收，如果是最后一个，则会打印至控制台
或者可以使用1> log.txt将标准输出 pipe进文件

1

cat file.txt | node std.js | grep FOO 1> log.txt

在这里记录下nodejs各种小细节

ch1 Modules

作为一个新世纪的前端，npm早已经是我们生活中必不可少的工具了
那么，这其中有多少奇怪的事情呢

1. 全局安装不等于全局require

初学nodejs的时，听闻npm i xxx之后，便可以在项目中直接require使用了
又听闻有一个npm i xxx -g的全局安装命令，下意识以为这样安装之后在任何地方都可以require
其实不然,这个-g的意义更多的在于将nodejs写的命令行工具装在全局
这样就可以直接在命令行使用，而不需要敲全路径了

比如 npm i gulp -g
然后直接在命令行敲 gulp,就能使用它

如果想require全局的包，则需要设置 NODE_PATH 环境变量
指向nodejs全局安装路径的node_modules文件夹
window 目录: %USERPROFILE%\AppData\Roaming\npm\node_modules

2. 为什么要使用module.exports = xxx,而不是 exports = xxx

我们可以使用如下语句导出一个模块

1
2
3
4
5

exports.foo1 = bar1
exports.foo2 = bar2
// or:
module.exports = bar

而不能使用exports = bar
因为nodejs将你的模块文件包裹成

1
2
3
4

(function (exports, require, module, __filename, __dirname) {
   //your module
   // ...
});

其中exports是module.exports的引用
当我们改变exports的属性时，修改的是module.exports内存地址的对象
而当我们直接给exports赋值时，仅仅只是将exports指向的内存地址改变
而不会修改 module.exports的指向

3. 解除modules缓存

我们知道nodejs会自动缓存require的模块，以防止多次require重复加载文件浪费性能
那如果我们的场景需要清除缓存，该怎么做呢？
其实nodejs的模块都缓存在require.cache对象里面，模块的键都是其文件的绝对路径
而通过require.resolve(‘./module/name’)可以获取到模块绝对路径

1

delete require.cache[require.resolve('./module/name')]

就可以删除相对应模块的缓存

入行几年，想起头几年。插件横飞，flash乱入。

js就像一个寄生的物种，依附浏览器生存，随之而来的是谜之兼容。

入行者得感谢网景，从业者得感谢谷歌

前言

原先打算写一写关于以上的一些个人看法，又中途放弃，因为借助现在琳瑯满目的工具。以上存在的问题都不是问题。最后想了想前端本质还是为页面渲染响应服务，再多工具，只是为了服务自身，控制成本和质量，所以拎出性能这快，来说说自己想法。

先声明下,这里的坑并不是vue或浏览器的bug,只是我们在做translate动画时容易忽略的一个点.

假设我们要实现这样的效果:

首先声明一下，我们公司的开发流程比较严(fan)谨(suo)，真实环境并没有像本文这样自动部署的做法。
我们要达到的效果是：我们本地开发好的代码，推送到服务器后，服务器自动部署最新版本的代码。

这里介绍两种方式：

• 裸仓库方式
• 非裸仓库方式

这段时间折腾了一个vue的日期选择的组件，为了达成我一贯的使用舒服优先原则，我决定使用directive来实现，但是通过这个实现有一个难点就是我如何把时间选择的组件插入到dom中，所以问题来了，我是不是又要看Vue的源码？

vue2.0即将到来，改了一大堆，Fragment没了，所以vue社区中为数不多的组件又有一批不能在2.0中使用，vue的官方插件也是毁得只剩vuex兼容，所以在我正在折腾我的组件的时候看到这个消息我是崩溃的。。。但没办法，还是得继续。希望2.0出来之后官方能完善一下文档，1.0中太多东西根本没在文档里提到，比如Fragment，比如Vue的util方法，这给第三方组件以及插件开发者带来了无数的玛法，你只能去看源码了，费时费力，刚研究透又来个大更新，我真的想哭/(ㄒoㄒ)/~~

小伙伴们必定不会对下面这段清除浮动的代码感到陌生：

1
2
3
4
5
6
7
8
9
10
11
12

.clearfix:after{ 
    content: '';
    display: block;
    clear: both;
    height: 0;
    visibility: hidden;
}
*/
.clearfix{ /*兼容 IE*/
    zoom: 1;
}

今天，我们不谈BFC和IE6的haslayout，来探究clear:both这个看似不起眼的属性。

webpack是什么

官网是这么说的：

webpack is a module bundler.

即：

webpack 是一个模块捆绑器

我们告诉它入口模块，这个文件会依赖其他模块，经过webpack的处理，最终输出包含所有依赖模块的集成模块。这个集成模块不一定是单个模块，有时候为了按需加载，不是所有模块都被捆绑进主模块。输出的模块一般用于浏览器，我看到服务端代码也用webpack的- -

webpack有一个宗旨：一切皆模块
无论我们依赖的是js,css,less,json,图片,任何格式的文件都可以，统统require就搞定。
这里就要引出另外一个概念：loader。
loader是什么呢，顾名思义，就是加载器，我们需要为所有类型的模块指定相应类型的loader(js除外，在webpack出现之前，我们已经把js文件称为模块已经好多年了)。比如：

• css => css-loader
• less => less-loader
• json => json-loader
• es6模块 => babel-loader
• 二进制文件 => file-loader
• png => url-loader

loader可以链式调用，比如less模块，被less-loader处理完后可以被css-loader处理，再继续被style-loader处理。
另外，这里可以提一下，url-loader继承了file-loader, 如果模块的大小，小于指定值，则会返回一个Data Url以减少http请求，对于小图片的处理非常有用！