Unnecessary import-related warnings.

[harrysolovay]

Describe

I'm using a lock file to pin dependency versions & integrity. This means that I'd prefer to specify the short-form of a given import.

For instance...

- import { assert } from "https://deno.land/x/[email protected]/mod.ts";
+ import { assert } from "https://deno.land/x/conditional_type_checks/mod.ts";

When I cache my dependencies, I use the following:

deno cache --lock=lock.json --no-check=remote deps.ts

And all works beautifully, with no warnings in the command line.

However, the VSCode plugin doesn't pick up on the presence of a lock file, nor does there seem to be a configuration option for ignoring those specific warnings / specifying the lock file.

Screenshots

Versions

deno 1.19.0 (release, aarch64-apple-darwin)
v8 9.9.115.7
typescript 4.5.2
vscode: 1.64.2 (Universal)
vscode_deno: v3.10.1

Any help on getting rid of these warnings would be greatly appreciated! Thank you!

[kitsonk]

The warnings still stand. deno(redirect) is only info, but deno(deno-warn) if a warning. The CLI only ever displays it once when the module is first cached, irrespective of a lock file being used or not, but the language server displays it all the time as a warning so you are aware of it.

The lock file doesn't "remove" the redirect, nor does it invalidate the warning, it just help ensure that if the redirect changed at some point in the future and you deleted your cache, you would get errors, when attempting to run the program.

[harrysolovay]

Ahh, thank you for this useful info @kitsonk! In that case, can we transfer this issue into denoland/deno and convert it into a discussion?

I see you're working on a POC called "Pin." I'm wondering if you or anyone else in the community could suggest best practices around minimizing the footprint of imports?

My current (haphazard, yellow-lit) approach: I've set up an import map with the following:

{
  "imports": {
    "std/": "https://deno.land/std/",
    "esm/": "https://esm.sh",
    "x/": "https://deno.land/x/",
    "/": "./",
    "./": "./"
  }
}

This way, I don't worry about re-exporting from a central deps file. It's clear where each of these imports points. And the URLs are simple.

// From std
import * as asserts from "std/testing/asserts/mod.ts";
// From esm
import ts from "esm/typescript";
// From x
import * as cc from "x/cliffy/command/mod.ts";
// From root
import { myLocalA } from "/my_local_a.ts";
// From current dir
import { myLocalB } from "./my_local_a.ts";
// From parent dir
import { myLocalC } from "../my_local_c.ts";

There are two issues with this (imo simpler) approach:

• Specifying versions would bloat the URL subpaths
• I might accidentally specify different versions in different files

Ideally, this would be managed by part of the toolchain at "lock" time to spare me the cognitive overhead.

Thoughts?

[bartlomieju]

Let's continue in #777.