[Discussion] Modules that can break other modules.

Hello All. This issue is going to be a bit long as explanation is needed, but it will have a point.

On Monday, June 1 at about 5am, the code of one of my projects broke. The error was quiet interesting

error: TS2578 [ERROR]: Unused '@ts-expect-error' directive.
  // @ts-expect-error
  ~~~~~~~~~~~~~~~~~~~
    at https://deno.land/std@0.54.0/ws/mod.ts:494:3

it turns out that nowhere in my code I was importing https://deno.land/std@0.54.0/ws/mod.ts so I thought about a third-party module broke my module. After hours investigating, it turns out that Oak has committed a change to deps.ts file that included https://deno.land/std@0.54.0/ws/mod.ts, at first I looked for the dependencies of Oak my module uses, and I made them target to oak@v5.0.0 as that version didn’t have the inclusion that was breaking my code, but after that, my code continued breaking and I knew something weird was going on with a third-party module. First, I thought about it, then I was sure.

Long story short, One of my third-party modules was calling a different version of oak in relation to the version of oak my app was using, and this was breaking the code, not because of my app itself, but because of the codes that were being included in the third-party oak import.

I believe this is dangerous issue & should be addressed carefully, it requires a lot of discussion. The main points are:

1. Third-party modules can break your module easily.
   1. This is extremely unaffordable in production environments.
2. There should be a warning when a module is not imported with a target version.
3. There should be a deno flag/configuration to allow or not allow imports directly from the master branch as this would give more control to the developer over what kind of third-party libraries are being used and whether they could break the code.
4. Possibly, there should be an option to have a “force import”, this would mean, if your module is forcing a version on a file from a module, and a third-party requires the same file from the same module but it is requesting the master branch, then through the “force import”, Deno would know that you have already specified a version to that file of that module and thus that one should be the file to be used for all the modules (inside your app or third-party) that require it.
   1. This would give more flexibility to the developer on what kind of imports to use, as if the code breaks, the developer already knows that there is a conflict of versions and it is the developer’s fault & responsibility to get the work around it.

This is something that requires a lot of discussion, but it is definitely something that needs to be addressed. There is a clear example of this. My application broke for over 10 hours, and this could have happened in pre-production environments, even worse, some scenarios can make this happen in production. This has been addressed several times I believe, but as of right now, nothing clear.

Thank you for reading, I can’t wait to read your opinion on this and your possible solutions.

Regards, Juan.

CC: @lucacasonato

[lucacasonato]

I think there is a point to be made here that we can improve the semantics around importing implicit master for deno.land/x. I propose the following:

1. Use the existing X-Deno-Warning infrastructure to add a warning to all requests that use an implicit version, not just std.
2. Add a "implicit_default": "warn" key in the database.json so every module can choose for itself if implicit versions should warn or not. This could later even be extended to a "implicit_default": false which would disable implicit version importing all together.
3. Add a link to deno.land/x in the warning to where people can find out more about why an implicit default is bad.
4. Add a import trace to the warning in Deno.

WDYT?

[nayeemrmn]

Ah I see, you used a locked version of a module that used an unlocked version of oak. This isn’t really an earth shattering issue with Deno, the module you’re using is faulty because it does this. Kind of like a module that is coded to throw a random error after a certain date, which it may as well be. Raise a bug report with them or use something else.

You can catch these situations properly using lock files. There are couple of ways to recover from them:

• Use an import map to override that module’s oak@master import.
• Use this pattern so the expected source is always available and being used.