使用vscode一键断点调试typescript

本来我是webstorm死忠,只是近一年来vscode发展迅速,感觉其性(功能)价(内存)比已经超过webstorm,虽然有一些细节功能还不如webstorm,不过就typescript而言,同是微软自家的东西,会支持的更好一些,所以近来就转战vscode了~

目前typescript的断点调试方案,很多编辑器/IDE官方或一些技术博文,大多都是先手动(或其他相对自动化的方式)编译生成javascript以及相应sourcemap,然后以javascript为入口进行调试。
这种方式,还是不够便捷。

本文介绍的断点调试,『无需手动编译ts文件』,就像调试javascript代码一样,乃真正的『一键』调试。另外,本文针对node环境的代码进行调试,对于前端代码不一定试用

cnpmjs.org实战

对Nodejs有一定了解的童鞋都应该知道,国内访问官方源 (https://registry.npmjs.com )需要漂洋过海,对模块的安装速度影响很大。

cnpm的诞生为国内Nodejs从业者带来了福音,向cnpm开发团队致敬~

此前,同事在公司内部搭建了一个cnpmjs.org@2.12.2, 部署方式基于源码克隆 + MySql(以下称『旧cnpm』)。

近日,由于某种原因,需要在另一台服务器(ubuntu16.04)重新搭建一个cnpmjs.org实例(以下称『新cnpm』)。

ueditor之一波多折

首先要承认,百度前端团队出品的ueditor可能是所有开源富文本编辑中,功能最全的一款编辑器。虽然2016年百度公司整体的业界口碑有所下滑,但是攻城狮的开源精神始终是值得称赞的。核心源码并没有细看,但从整个库的使用方式来看,模块化方案似乎做的并不是很好,后来百度的echarts这方面就做的好一些,另外它的版本号规范不符合semver规范,不过它本身也不支持npm包的使用方式。

git log --follow奇遇记

本来已经口头分享给几个小伙伴了,后来想想,为了让更多小伙伴们少踩坑,还是写出来。

早前读《Git 版本控制管理》,书中提到git flow--follow参数用于追溯文件重命名前的历史记录,当时觉得挺好理解。谁知这次遇上了一个神奇的现象,且听我娓娓道来。

谈谈微信WEB调试

现如今,国内移动端WEB开发,几乎都离不开微信(阿里系产品除外),然而在微信里,WEB存在于WebView,不像原生Safari可以通过Mac Safari那样断点调试。
更要命的是,微信SDK的调试,必须基于域名,这给调试带来很大的麻烦。

距离上一次讨论移动端WEB调试(介绍两种移动设备调试方案),已经过去了近一年半时间。这一年半时间里WEB前端又是一阵风起云涌,微信调试又有哪些新玩法呢?

Surge for Mac 2 初体验与教程

使用Surge for Mac已有两周,今日写下一路以来的感受,并给后来的小伙伴填坑铺路。如果想看Surge for iOS教程,请继续Google,本人认为iOS下用小火箭足以。需要强调的是,Surge只是一款网络工具,支持多种网络协议,但本身并不提供出墙功能,需要自己搞定ss账号,可以直接从ss提供商购买,或是自己购买VPS搭建ss服务。

先放大招:

[前端攻城狮]可能是使用Mac Surge性价比最高的职业!

为什么?
因为前端攻城狮:懂编程,懂正则,要抓包,爱折腾,更需要科学上网!

早就听闻Surge的大名,由于其高昂的价格,一直将其拒之门外。直到看到池大大这篇文章 Surge for Mac 快捷如风,我动心了。于是第二天在公司里众筹买了Mega License,当天也是各种忙,到了周末在家一顿鼓捣。

Google了一晚上,找到的文章,大部分讲的是Surge for iOS或者Surge for mac 1.x,我看的莫名其妙。其中几篇提供了配置文件模板,但大都讲的不清不楚。
当天晚上我是一头雾水,困觉去了。真是应了其中一篇文章所说,Surge的使用,确实需要门槛。

第二天不死心,继续折腾,回顾了所有看过的文章,并结合我当前的Surge版本的面貌,终于成功折腾出了一个能科学上网的ss配置。随后就一发不可收,哇擦咧,此乃神器也!

npm install之依赖冗余

首先这是一个问题,但通过标题没法很好的表述出来,而大多数童鞋应该不会遇到这样的问题,然而我还是决定记录下来。

我们知道,npm3把所有依赖模块路径拍扁了(工程目录下的node_modules出现了很多package.json中没有声明的模块),解决了windows下路径名过长的问题,更使得公共依赖被充分共享。但如果多个模块依赖了同一个模块的不同版本,后安装的模块,为了不和别人冲突,就只能将这个依赖安装在自己的node_modules下。

模块系统之 CommonJS vs ES6

想了半天标题,终于决定还是它了。主要就是对比两个规范下的模块系统。
对于ES6模块系统,截止目前还没有环境原生支持,大多通过babel转换来实现。node环境的模块系统本身就是CommonJS的一个实现,浏览器环境通过webpack进行构建也可以支持大部分CommonJS,所以这个话题多数场景与宿主环境没有直接关系。

接下来开始VS:

导入模块

CommonJS:

1
2
const Koa = require('koa')
const app = new Koa()

ES6:

1
2
import Koa from 'koa'
const app = new Koa()

看起来似乎ES6更加『正统』,还霸占了两个关键字呢(/得意).

使用git钩子自动部署服务

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

这里介绍两种方式:

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