Importing a typescript module

I have been trying to use @creditkarma/thrift-parser@1.0.4 which is an npm package.json written in typescript, but I get the following errors:

import => Error: unable to load module

import with try/catch => TypeError: Failed to fetch dynamically imported module: unpkg.com/@creditkarma/thrift-parser@1.0.4/dist/main/index.ts

wzrd.in => TypeError: Failed to fetch dynamically imported module: wzrd.in/standalone/@creditkarma/thrift-parser@1.0.4

require with try/catch: Error: invalid module
at HTMLScriptElement.r.onload (static.observableusercontent.com/worker/worker.84624bfaa8195ae8aae34c70e6a12fd2021308e0cce2ed522b3ef0a60a588a36.js:2:43374)

Hi Jay,

Sure - so, like most TypeScript modules, the entry point for this one is just JavaScript - it includes extracted typings in a .ts file, but given that no JavaScript runtimes support TypeScript, it doesnā€™t point to TypeScript. That said, the file that its package.json points to uses CommonJS - you can decipher this y going to https://unpkg.com/@creditkarma/thrift-parser@1.0.4/, checking the path in package.json, and then clicking to the file mentioned.

What Iā€™ve found that works for this one is using bundle.run, though Iā€™m pointing it to 1.0.3 rather than 1.0.4 - bundle.run had trouble bundling the newest revision:

require('https://bundle.run/@creditkarma/thrift-parser@1.0.3')

Perhaps by tomorrow bundle.run recovers from that instability and can bundle 1.0.4.

  • Tom

Sweet! Iā€™m not well versed in JS packaging, so all these magical wrapper sites are like secret incantations. I love how easy it is to learn with Observable ā€“ once you get a library loaded it is the quickest and easiest way to experiment.

Thanks for the quick solution!
jay

Minor update for any folks struggling with requiring packages: I just wrote a module require debugger that, for many modules, will quickly identify a working strategy:

5 Likes

propel is all-frowny face

Thatā€™s the hardest pattern! And the one I punted on for the initial notebook :wink:

But I just implemented it - the notebook now identifies the ā€˜global leaks patternā€™, and correctly guides you to a working strategy for propel, and for other modules that follow its pattern.

cool!. Looks like require('https://unpkg.com/propel').catch(() => window.propel) works too

(the plot part still escapes me)
[EDIT] propel.plot is half-solved here https://beta.observablehq.com/@thadk/hack-propel-plot-to-work-in-observable

Dear @tom

This is so handy. When I tried it on lib-r-math.js, which says that it works with a global leak pattern, I just get undefined:

require('lib-r-math.js@1.0.75/dist/lib/libR.js').catch(() => window.libR)

This appears more to be a webpack issue when packaging for node, such that the bundle requires tty (which is node, not on npm) and utils. I re-packaged for web, and now I can just use a vanilla require:

https://beta.observablehq.com/@sdwfrost/librmath

Ah, yeah - thatā€™s another variant in which our exposing require actually handicaps the module requiring, due to how lib-r-math is packagedā€¦ will have to meditate on how to detect / import that style, and whether that style of bundled module will crop up in the future.

I am trying to require the p5.dom library for p5.js ā€“ e.g. using the version on cloudflare. I tried the module require debugger notebook, which suggests:

require('p5@0.6.1/lib/addons/p5.dom.js')

ā€¦but this results in undefined in the Observable notebook. Adding .catch() => .catch(() => window.p5dom also results in undefined.

@tom ā€“ does this look the same as the libR.js issue above, or is this a different issue?

Thatā€™s another issue - p5.dom doesnā€™t expose anything, it only augments the p5 module. Hereā€™s a notebook that requires it: https://beta.observablehq.com/d/8f3f7067f7d32421 and the relevant code:

p5 = require('p5').then(async p5 => {
  await require('p5@0.6.1/lib/addons/p5.dom.js');
  return p5;
})