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)

1 Like

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;
})