Deno 1.2.0: Url Argument Type Solutions

Intro

hmm, yesterday, some of us, Deno Devs (or Denosaurs or...) had a really rude experience with deno upgrade.
Like each time there's a new version we naturally decided to switch and upgrade to the new version.
I think this is a really good lesson for me and perhaps others. you're gonna see why.
Deno 1.2.0 came with a "breaking" change or I don't know how to call it, that slowed down many modules development, like Mandarine.ts from Andres Pirela or Ogone for myself.
this version implements a new Argument type for URL, it says:

TS2345 [ERROR]: Argument of type 'string | URL' is not assignable to parameter of type 'string'.
Type 'URL' is not assignable to type 'string'.

The main problem is ... this is not my code... so something were broken but I didn't know where.
after a discussion in discord, we saw that std/path version under 0.61.0 is broken (in my case) on Deno 1.2.0.

Fix

So, the first thing I did: upgrade the std/path in deps.ts to 0.61.0 (if you got one in your module, or in mod.ts). after this, the same issue came out: new Url(bruh) is not assignable .. that was not enough and I had to learn how to inspect the dependency tree by using: deno info --unstable --no-check deps.ts

--no-check will say to the typescript compiler to omit the errors. and --unstable is to allow the unstable features of Deno.

this should print a large list like following:

for me that was plugin_prepare, used by Deno Sass that were using an old version of std/path (0.51.0). after a Pull Request this were fixed.

Solutions

• Avoid using master branch: you guys need to put the version on the imports, especially for the deno.x modules. master's branch is by definition unstable. do deno.land/std@[version]/[module]/.... do it now for all your dependencies

• Deno info: use deno info --unstable --no-check deps.ts like explained above to inspect which module is using an old deno.std version.

• Pull Request: if you're in the same case with a dependent sub-module, you need to make a PR or ping the maintainers and tell them to use supported version of deno.std in Deno 1.2.0

• Downgrade: deno upgrade --version 1.1.3 and wait for all the sub-modules to change the versions.

• the sub-module is no more maintained: erase it.

• also: keep in mind deno.std are still unstable.

Acknowledgements

• @yamboy
• @lucasonato

related sources:

• The issue

See also:

• Nest.land package registry for Deno with immutable packages using Blockchain
• Deno Sass module binding Sass CSS Pre-Processor for Deno
• Ogone Web Components-Compiler, Client Side Rendering for Deno.
• Mandarine.ts is a framework that allows you to create applications.

Comments

[Zane Milakovic]

Nice write up.

I have been using comments to track the version I am on. Then after every upgrade, I run my test suite. And I separated by deps.ts into a standard import section and a third party section.

I try to be very clear on what version everything is set too. And I am relying on documentation, for now, to try and be very clear.

Example of my deps.ts

/**
 * Standard Libraries - Tagged to 0.65.0 for Deno 1.3.0
 */

// Assert
export {
  assert,
  assertEquals,
  assertThrows,
} from "https://deno.land/std@0.65.0/testing/asserts.ts";

// Benchmarks
export {
  runBenchmarks,
  bench,
} from "https://deno.land/std@0.65.0/testing/bench.ts";

// Colors
export {
  bold,
  cyan,
  green,
  yellow,
  red,
  bgGreen,
  bgYellow,
  black,
} from "https://deno.land/std@0.65.0/fmt/colors.ts";

/**
 * Third-Party Libraries
 */

// Some Library v1.20
export { something } from "https://deno.land/x/something@v1.2.0/mod.ts";

[Rudy Alula]

yeah pretty cool
be sure to use --reload after upgrade to ensure the validity of all the dependencies