Error executing sample script from https://deno.land/x/opine about opine

[rglowrey]

No, didn't fix it.

Here's the code I ran:

import { opine } from "https://deno.land/x/[email protected]/mod.ts";

const app = opine();

app.use((req, res) => {
  res.send("Hello World");
});

app.listen(3000);

Here's the result:

rick@rick-XPS-8920:~/Working/Playpen/deno/OpineTemplate$ deno run --allow-net sampleOpine.ts
Check file:///home/rick/Working/Playpen/deno/OpineTemplate/sampleOpine.ts
error: TS2305 [ERROR]: Module '"./_utils"' has no exported member 'normalizeEncoding'.
import { notImplemented, normalizeEncoding } from "./_utils.ts";
                         ~~~~~~~~~~~~~~~~~
    at https://deno.land/std/node/buffer.ts:3:26

[asos-craigmorten]

@rglowrey ah yes, saw this is in one of my other repos - one of the subdependencies hasn’t locked its versions causing this issue - I’ll get a patch out this morning shortly.

[asos-craigmorten]

@rglowrey please can you try out 0.17.0 and see if that is fixed for you? 🙂 I would also recommend always using a specific version of opine - the main branch is not 100% guaranteed to be stable (though is generally the plan!).

REF: https://github.com/asos-craigmorten/opine/releases/tag/0.17.0

[asos-craigmorten]

@rglowrey Hmm... the classic and somewhat unhelpful "works for me"!

Can you try with the --reload flag? I wonder if you've got a cached "bad" subdependency somewhere? I.e.

$ deno run --allow-net --allow-read --reload sampleOpine.ts

[rglowrey]

Now I get to give the classic "so it really WAS me all along!". Yes, running with the --reload flag did the trick. Also, when I ran it with the first line
import { opine } from "https://deno.land/x/opine@main/mod.ts";
it worked fine after that --reload. Thanks for your help, and sorry for the bother.

[asos-craigmorten]

@rglowrey no bother at all! I believe the initial problem lay with Opine 😂 or specifically one of it's dependencies - something I think needs ironed out in Deno is sub-dependency resolution, conflicts etc. I don't think there is a way to "lock" versions for consumers of a module. The only thing consumers can do afaik is find a "good" version and then use the --lock-write and subsequently --lock flags to protect themselves from these errors - I don't think it can be fixed upstream just yet...?

Glad it works now anyway!