[Feature Request] 将「包存在，但是包的具体某个版本不存在」这一条件添加为 syncNotFound 功能的触发条件

[baxtergu]

• 需求描述

在企业内私有 npm 仓库服务的这个用户场景下，一般会使用 syncMode: 'EXIST' 模式进行服务的运行。当搭配 syncNotFound: true 使用时可以覆盖“当某个包不存在仓库里时，返回 Not Found，但随之触发一次这个包的同步任务”这个场景。

但是，希望能够在这个能力的基础上做一些扩展，支持 “当某个已经存在的包的指定版本不存在时，返回 Not Found，随之触发一次这个包的同步任务” 的行为。

其目的主要是为了有一种可以通过用户安装来触发版本增量更新的能力，而尽量少的手动触发。而 changeStream 的订阅能力在企业内部复杂的网络条件的情况下很有可能会不稳定，达不到预期的效果。

• 可能的实现

cnpmcore/app/port/controller/package/ShowPackageVersionController.ts

Lines 27 to 49 in 072e146

	async show(@Context() ctx: EggContext, @HTTPParam() fullname: string, @HTTPParam() versionSpec: string) {
	// https://github.com/npm/registry/blob/master/docs/responses/package-metadata.md#full-metadata-format
	ctx.tValidate(Spec, `${fullname}@${versionSpec}`);
	const [ scope, name ] = getScopeAndName(fullname);
	const isSync = isSyncWorkerRequest(ctx);
	const abbreviatedMetaType = 'application/vnd.npm.install-v1+json';
	const isFullManifests = ctx.accepts([ 'json', abbreviatedMetaType ]) !== abbreviatedMetaType;
	const { blockReason, manifest, pkg } = await this.packageManagerService.showPackageVersionManifest(scope, name, versionSpec, isSync, isFullManifests);
	if (!pkg) {
	const allowSync = this.getAllowSync(ctx);
	throw this.createPackageNotFoundErrorWithRedirect(fullname, undefined, allowSync);
	}
	if (blockReason) {
	this.setCDNHeaders(ctx);
	throw this.createPackageBlockError(blockReason, fullname, versionSpec);
	}
	if (!manifest) {
	throw new NotFoundError(`${fullname}@${versionSpec} not found`);
	}
	this.setCDNHeaders(ctx);
	return manifest;
	}

在这里增加如下逻辑：

     if( (pkg && !manifest) {
        throw this.createPackageNotFoundErrorWithRedirect(fullname, undefined, allowSync);
    }

一般内部私有仓库情况下这种触发不会很频繁，并且 sync 任务已有的合并同步能力可以解决短时间重复创建同一个包的多次同步任务这一情况。

以上

[fengmk2]

挺好的，可以来一个 pr 实现。

[baxtergu]

好的，我来提一个

[hezhengxu2018]

我觉得这个需求和 #366 非常的类似？这个功能的大部分的工作都完成了，如果是的话没必要重复开发了。

[baxtergu]

我觉得这个需求和 #366 非常的类似？这个功能的大部分的工作都完成了，如果是的话没必要重复开发了。

有点类似但是不太一样。我的应用场景下的 cnpmcore 并不是直接从公网同步而是从内网的一个代理模式的中间仓库同步，有很多不可控因素。需要尽量保证提供给用户使用的 cnpmcore 仓库中已有的包版本尽量新和全，代理模式达到这一点更多需要依赖上游仓库的稳定可靠，但是我们这个场景没法保证。

[hezhengxu2018]

代理模式就是为了缓冲上游仓库不稳定网络的情况使用的，它不要求上游仓库完全的稳定可靠。代理模式会缓存所有经过代理仓库安装的依赖，此后即使上游仓库完全无法访问也不会影响内网曾经使用过的依赖的安装。

[hezhengxu2018]

代理模式下访问一个该仓库不存在的包时也会创建一个同步该版本包的任务，和你不同需求的是代理模式在同步任务执行完成之前都会从上游仓库反向代理而不是返回not found

[baxtergu]

代理模式下访问一个该仓库不存在的包时也会创建一个同步该版本包的任务，和你不同需求的是代理模式在同步任务执行完成之前都会从上游仓库反向代理而不是返回not found

我的场景实际需要的是： EXIST 模式 + （Proxy Not Found & Sync）。其实只需要在 Exist 模式上一些增强就可以满足了，切换模式对于已在正常运转的仓库来说风险比较高。