回顾 is-promise 库迁移 ESM 事故

is-promise 只做一件事,判断 JavaScript 对象是否为 Promise,但这个包被近百万个项目所依赖。作者在 4月25日发布的新版本并未遵循正确的 ES 模块标准,从而导致更新完成后,所有在构建时使用 is-promise 库的项目几乎全部报错。

这里犯了几个个错误 https://github.com/then/is-promise/blob/8e51d62bf158eb0685cd6109f0137472e8c3cb91/package.json#L7-L10

  • 以为 exports 和 main 一样,但实际上需要 ./ 前缀。
  • exports 不仅限制你能导入什么,还得限制你怎么导入

exports 字段

我们都知道 node 模块导出有 main ,所有版本的Node.js都支持,但是能力有限:它仅定义包的主要入口点。

"exports"扩展了 main,而且二者同时存在时,优先使用 exports。

Node.js支持以下条件:

  • "import" 通过import或 加载包时匹配import()。可以同时引用ES模块或CommonJS文件, import并且import()可以加载ES模块或CommonJS源。
  • "require"通过加载包时匹配require()。由于require()仅支持CommonJS,因此引用的文件必须为CommonJS。
  • "node"适用于任何Node.js环境。可以是CommonJS或ES模块文件。这种情况应该总是在"import"或 之后出现"require"。
  • "default"是CommonJS或ES模块文件,应始终排在最后。

条件导出

一个package.json文件可以直接定义单独的CommonJS和ES模块入口点:
条件匹配的规则是从上至下,所以应按对象顺序使用从最具体到最不具体的条件。

 "exports": {
    ".": [
      {
        "import": "./index.mjs",
        "require": "./index.js",
        "default": "./index.js"
      },
      "./index.js"
    ]
  },

嵌套条件

"exports": {
    "browser": "./feature-browser.mjs",
    "node": {
      "import": "./feature-node.mjs",
      "require": "./feature-node.cjs"
    }
  }

参考文章:
https://github.com/then/is-promise/issues/13
https://medium.com/javascript-in-plain-english/is-promise-post-mortem-cab807f18dcc

Nuxt 实现组件缓存

组件缓存

nuxt 中提供了 bundleRenderer 选项,它会作为vue-server-renderercreateRenderer方法的配置。其中cache对象必须getset方法。

type RenderCache = {
  get: (key: string, cb?: Function) => string | void;
  set: (key: string, val: string) => void;
  has?: (key: string, cb?: Function) => boolean | void;
};

lru-cache创建的实例包含了getset方法,所以可以直接配置。

export default {
  render: {
    bundleRenderer: {
      cache: require('lru-cache')({
        max: 1000,
        maxAge: 1000 * 60 * 15
      })
    }
  }
}

然后可缓存组件必须定义一个唯一name选项。如果渲染结果也依赖于prop,那么还需要修改serverCacheKey的计算方式。如果serverCacheKey明确返回false,那么就将直接抛弃缓存,重新渲染。

name: 'Date',
serverCacheKey: props => props.item.id,

你也可以安装@nuxtjs/component-cache,它也是使用lru-cache实现的组件缓存。但使用lru-cache在内存中进行缓存的缺点也很明显,开启多进程时每个进程都会缓存一份资源浪费,也有可能出现缓存不一致的情况。

不应缓存的组件

缓存组件必须十分谨慎,下面的组件是不能缓存的:

  • 具有可能依赖于全局状态的子组件。
  • 有子组件会在渲染上产生副作用context。

参考文章

https://gist.github.com/Tuarisa/b7c07289eb32b2a7a77be270e1c8360f

Jest mock 函数和模块

Jset 中有几种创建模拟函数的方法。该jest.fn方法允许我们直接创建一个新的模拟函数。如果要模拟对象方法,则可以使用jest.spyOn。如果要模拟整个模块,可以使用jest.mock。

mock 函数

Jest 可以捕获对函数的调用(包括调用中传递的参数),也可以直接擦除函数内部的实现,直接返回mock的结果。

function getDouble(val, callback) {
  if(val < 0) {
    return;
  }
  setTimeout(() => {
    callback(val * val);
  }, 100);
};

const mockFn = jest.fn();
getDouble(10, mockFn);

expect(mockFn).not.toHaveBeenCalled()
setTimeout(() => {
  expect(mockFn).toHaveBeenCalledTimes(1);
  expect(mockFn).toHaveBeenCalledWith(20);
}, 110);

mock 模块

import {getParameter, getFilterInfo} from "../service";


jest.mock('../service');
getFilterInfo.mockResolvedValue([model])
getParameter.mockResolvedValue(parameter)

参考文章

https://www.pluralsight.com/guides/how-does-jest.fn()-work

使用 Jest 对 Nuxt 应用进行单元测试

配置 jest.config.js

module.exports = {
  // tell Jest to handle `*.vue` files
  moduleFileExtensions: ["js", "json", "vue"],
  watchman: false,
  moduleNameMapper: {
    "^~/(.*)$": "<rootDir>/$1",
    "^~~/(.*)$": "<rootDir>/$1",
    "^@/(.*)$": "<rootDir>/$1"
  },
  transform: {
    // process js with `babel-jest`
    "^.+\\.js$": "<rootDir>/node_modules/babel-jest",
    // process `*.vue` files with `vue-jest`
    ".*\\.(vue)$": "<rootDir>/node_modules/vue-jest"
  },
  snapshotSerializers: ["<rootDir>/node_modules/jest-serializer-vue"],
  collectCoverage: true,
  collectCoverageFrom: [
    "<rootDir>/components/**/*.vue",
    "<rootDir>/pages/*.vue"
  ]
};

配置 Babel config

function isBabelLoader(caller) {
  return caller && caller.name === "babel-loader";
}

module.exports = function(api) {
  if (api.env("test") && !api.caller(isBabelLoader)) {
    return {
      presets: [
        [
          "@babel/preset-env",
          {
            targets: {
              node: "current"
            }
          }
        ]
      ]
    };
  }
  return {};
};

添加测试脚本到 package.json

"test": "jest --colors --verbose"

因为Jest 的测试文件中的方法是全局的,所以一般编辑器不会给提示,如果想要编辑器有提示的话可以安装 @types/jest

参考文章

https://medium.com/@gogl.alex/nuxt-jest-setup-from-scratch-8905d3880daa
https://medium.com/@brandonaaskov/how-to-test-nuxt-stores-with-jest-9a5d55d54b28

Javascript 中的 RAII?

RAII 的全称是 “Resource Acquisition is Initialization” 1(资源获取即初始化),它是C++之父Bjarne Stroustrup提出的设计理念,目的是确保异常下的资源管理。换句话说,不管当前作用域以何种方式退出,都会执行资源释放等操作。

C++中 RAII 应用很广,C++11 中的两种基本的锁类型,lock_guard 和 unique_lock ,通过对lock和unlock进行一次薄的封装,实现了自动unlock。

std::lock_guard其功能是在对象构造时将mutex加锁,析构时对mutex解锁,这样一个栈对象保证了在异常情形下mutex可以在lock_guard对象析构被解锁,lock_guard拥有mutex的所有权。

使用try { ... } finally { ... }语句也可以实现类似效果。

下面是在 Node 中写文件为例,我们需要显式关闭流。

function hello(cb) {
  var stream = fs.createWriteStream('example.txt')
  stream.write('Hello World')
  stream.close()
}

如果在两者之间抛出异常,流将泄漏;至少直到下一次垃圾回收为止。

我们可以使用闭包或Promise,创建流然后调用处理程序,最后的finally确保我们可以正确关闭流。

function usingWriteStream(name, handler) {
  var stream = fs.createWriteStream('example.txt')
  try {
    return handler(stream)
  } finally {
    stream.close()
  }
}

function hello() {
  usingWriteStream('example.txt', (stream) => {
    stream.write('Hello World')
  }
}

更进一步,Node中创建流的函数有很多,所以我们还能改造一下,把流的创建函数作为参数。

var usingWriteStream = (name, handler) =>
  usingStream(fs.createWriteStream.bind(null, name), name)

多亏了闭包,我们可以在Javascript中构建类似于RAII的模式,以确保我们的资源不会泄漏。
即使在无法立即识别“资源”的情况下,这在许多情况下也很有用。

例如 Immutable.js 中的 [Map.withMutations()] 使用相似的模式:

const { Map } = require('immutable')
const map1 = Map()
const map2 = map1.withMutations(map => {
  map.set('a', 1).set('b', 2).set('c', 3)
})
assert.equal(map1.size, 0)
assert.equal(map2.size, 3)

这里会创建2个而非4个新的Map,可变 map就是资源。这样可以确保此对象不会轻易泄漏到当前作用之外,并且可以正确地将其转换回不可变 Map。

在C#中有一个 using 语法 ,其实就是 finally 的语法糖。我们可以在TS中去模拟:

interface IDisposable {
    dispose();
}

function using<T extends IDisposable,
    T2 extends IDisposable,
    T3 extends IDisposable>(disposable: [T, T2, T3], action: (r: T, r2: T2, r3: T3) => void);
function using<T extends IDisposable, T2 extends IDisposable>(disposable: [T, T2], action: (r: T, r2: T2) => void);
function using<T extends IDisposable>(disposable: T, action: (r: T) => void);
function using(disposable: IDisposable[], action: (...r: IDisposable[]) => void)
function using(disposable: IDisposable | IDisposable[], action: (...r: IDisposable[]) => void) {
    let disposableArray = disposable instanceof Array ? disposable : [disposable];
    try {
        action(...disposableArray);
    } finally {
        disposableArray.forEach(d => d.dispose());
    }
}


// Usage
class UserNotify { dispose() { console.log("Done"); } }

class Other { dispose() { console.log("Done Other"); } }

using(new UserNotify(), userNotify => {
    console.log("DoStuff");
})
// It will type the arrow function parameter correctly for up to 3 parameters, but you can add more overloads above.
using([new UserNotify(), new Other()], (userNotify, other) => {
    console.log("DoStuff");
})

上面的种种还是没法和RAII比,特别是在释放的资源有多个的时候,只能在 finally 中挨个检查各个资源是否已经被申请。例如:

  void f()
  {
    try {
      acquire resource1;
      … // #1
      acquire resource2;
      … // #2
      acquire resourceN;
      … // #N
    } finally {
      if(resource1 is acquired) release resource1;
      if(resource2 is acquired) release resource2;
      …
      if(resourceN is acquired) release resourceN;
    }
  }

参考文章:

https://stackoverflow.com/questions/47788722/idisposable-raii-in-typescript/47792127#47792127
https://www.zhihu.com/question/20805826