Shortly after this, Deno aborts type-checking. From the snippet above, we can see that the associated X-TypeScript-Types header leads Deno to attempt importing from /error/buffer?from=bson. Notably, this URL is the user-facing error that Skypack returns when it "detects a problem with a package ahead-of-time". The error reports that there is a "malformed URL", but I'm not exactly sure why (and where) this is the case.
Some Considerations
We know that bson depends on buffer. The buffer package is supposed to be a browser-compatible polyfill for Node.js' Buffer API. It is important to note that both bson and buffer provide appropriate type declarations. Indeed, the Skypack registry detects these declarations—at least according to the check mark (✔) found beside the "TypeScript Types" section of the package scores.
However, the problem occurs when we import bson?dts on its own. Strangely, the X-TypeScript-Types redirects to valid type declarations except for the first line:
// File: bson.d.ts
import { Buffer } from '/error/buffer?from=bson';
// --snip--
// Rest of bson's type declarations here...
Here, we see that the Skypack's bson type declarations fail to resolve to that of buffer?dts. This is unexpected because we know for certain that importing buffer?dts yields no errors. To prove that this is indeed the case, note the following output from deno info:
Thus, there are no issues when resolving buffer?dts on its own. The error only occurs when importing buffer?dts via bson?dts. Could it be the case that Skypack mistakenly polyfills Buffer instead of resolving to the buffer package?
Additional Context
This issue comes as a result of denodrivers/deno_mongo#290. It was found that CI was broken due to Deno failing to resolve the /error/buffer?from=bson import.
The Problem
I believe the following output from
deno infoshould be sufficient in explaining the problem:Shortly after this, Deno aborts type-checking. From the snippet above, we can see that the associated
X-TypeScript-Typesheader leads Deno to attempt importing from/error/buffer?from=bson. Notably, this URL is the user-facing error that Skypack returns when it "detects a problem with a package ahead-of-time". The error reports that there is a "malformed URL", but I'm not exactly sure why (and where) this is the case.Some Considerations
We know that
bsondepends onbuffer. Thebufferpackage is supposed to be a browser-compatible polyfill for Node.js' Buffer API. It is important to note that bothbsonandbufferprovide appropriate type declarations. Indeed, the Skypack registry detects these declarations—at least according to the check mark (✔) found beside the "TypeScript Types" section of the package scores.However, the problem occurs when we import
bson?dtson its own. Strangely, theX-TypeScript-Typesredirects to valid type declarations except for the first line:Here, we see that the Skypack's
bsontype declarations fail to resolve to that ofbuffer?dts. This is unexpected because we know for certain that importingbuffer?dtsyields no errors. To prove that this is indeed the case, note the following output fromdeno info:Thus, there are no issues when resolving
buffer?dtson its own. The error only occurs when importingbuffer?dtsviabson?dts. Could it be the case that Skypack mistakenly polyfillsBufferinstead of resolving to thebufferpackage?Additional Context
This issue comes as a result of denodrivers/deno_mongo#290. It was found that CI was broken due to Deno failing to resolve the
/error/buffer?from=bsonimport.