`no-import-prefix` is too aggressive

[scarf005]

was checking why the CI was breaking. i get why the rule was enabled in #30598 but maybe it should be an warning instead of an error considering it doesn't have autofix and migrating them all is quite a chore.

Version: Deno 2.4.5

[marvinhagemeister]

You can disable this rule in your project by making these changes to deno.json:

{
  "lint": {
    "rules": {
      "exclude": ["no-unversioned-import"]
    }
  }
}

[scarf005]

thanks, but this issue was more about whether the rule should be included in default ruleset rather than how to disable it.

[oscarotero]

I agree. This rule shouldn't be included by default.

[dsherret]

The rule is only enabled in a workspace. It's not enabled by default if you don't have a deno.json--you don't get this for single file scripts.

The reason is because when dependencies are specified across multiple scripts then it's not possible to get deterministic lockfile behaviour for installs because it requires running/caching all the files with specifiers in it. Additionally, specifiers cached in files are never removed from the lockfile once removed unlike specifiers in the config file.

In other words, if you put all the specifiers in the deno.json then you can just run deno install and get the same lockfile each time, which isn't true when they're spread out in files in a project. I've seen several issues caused by people confused about the behaviour of Deno because they're not putting specifiers in the config file.

[dsherret]

but maybe it should be an warning instead of an error considering it doesn't have autofix and migrating them all is quite a chore.

That said, this seems like a decent suggestion. Maybe we should introduce warnings and downgrade this as a warning for now.

[marvinhagemeister]

+1 for introducing warnings in our linter and making this a warning.

[Hajime-san]

I think this rule itself is useful from the perspective of dependency updates, as it doesn't support in-source updates, which is what I'm currently working on with Deno support for Renovate here renovatebot/renovate#37828.

[scarf005]

The rule is only enabled in a workspace. It's not enabled by default if you don't have a deno.json--you don't get this for single file scripts.

in practice, the 'workspace' rules is applied to majority of single file scripts, because they require deno.json for custom task, fmt, compiler options, etc.
unless we get to embed deno.json like rust script, single file scripts will have to resort to deno.json.

i'm firmly against no-import-prefix being the default lint rule with warning level error, considering

• there's no autofix for it
• it breaks the very premise deno had, modularity via https imports

[Hajime-san]

I agree with let's start from warning level, since it caused a breaking change, while deno doesn't recommend using http imports in production.

[oscarotero]

This is not compatible with http-import based libraries or frameworks like Lume. I can't add the specifiers to my import map since Deno doesn't load the import maps of http dependencies. I think this rule can be useful for orgs that follows the the npm/jsr way to install and load dependencies and can enable it for their workspaces. But Deno, by default shouldn't force this.