Multi-Runtime Monorepos / Importing Non-Deno Files

[bcheidemann]

Background

One of Deno's greatest strengths is the feeling of "it just works" that you get when using it. This is largely because it makes build tools like Webpack redundant. This makes Deno an attractive option for a wide variety of projects. Recently, however, I found myself wanting to add a Deno app to an existing monorepo. My experience has not been as painless as I had hoped.

Problem statement

Deno is hard to integrate into existing monorepos. This is in large part down to the way imports are resolved and the requirement for ".ts" extensions. This repo is a minimal demonstration of the issues one might face when trying to integrate Deno into an existing Monorepo. It also demonstrates how painless this is to set up with Bun.

The main issue here is that existing libraries in monorepos do not adhere to the same import rules as Deno (i.e. requiring ".ts" extensions). It's possible to work around this using the "allowImportingTsExtensions" rule and tediously going through every single import in every singe library and adding a ".ts" extension. However, this means that tsc can no longer be used to transpile the library, because "allowImportingTsExtensions" requires the "noEmit" flag. It also won't necessarily play well with other non-tsc build solutions.

Why is this important?

1. If Deno doesn't play nicely in existing project, this will limit future growth
2. Deno is currently unable to compete with Bun on this front - which "just works" as expected

Proposed Solution

In an ideal world this use case would "just work" without any consideration from the developer. This would require:

1. Deno to recognise when a ".ts" file is imported from a non-deno context
2. Deno to respect the "tsconfig.json" for non-Deno files

Off the top of my head, there's a couple different ways Deno could automagically recognise when a file is from a non-deno context:

1. Lack of deno.json - the issue here is that deno.json is not required in a Deno project
2. Presence of a tsconfig.json file - likewise tsconfig.json files could be included in Deno projects
3. Presence of a package.json file - same issue as point 2

Since automagically recognising when a file is a non-Deno file may not be possible/desirable for the above reasons, an alternative might be for developers to be able to indicate in some way when they are importing a non-Deno file.

The obvious solution would be to add a new URL scheme for this. There's already precedence for this with the npm: scheme. A node: URL scheme could therefore be introduced which would function similarly to the npm: scheme but for files from arbitrary URLs (not only packages published to NPM). Note: a different name would need to be used as node: is already used for importing Node built-in modules.

// Import local file with Node compatibility mode
import "node:./node-file.ts";

// Import remote file (bit janky due to "double scheme")
import "node:https://raw.githubusercontent.com/user/repo/main/index.ts";

Related Issues

• Revisiting "Custom URL Schemes or Configurable Resolvers for Imports" #16555
• Custom URL schemes or configurable resolvers for imports #2348
• Add support for unstable sloppy imports vscode_deno#1012

[bcheidemann]

This has been largely addressed by Deno v1.39.0 introducing the --allow-sloppy-imports flag in #21464. However, this flag is not yet supported by the Deno VS Code extension and deno check yields errors when type checking the example repo.

EDIT - 17/12/2023

As per @dsherret's comment on denoland/vscode_deno#1012, sloppy imports are actually supported by the Deno VS Code extension. The suggested config also resolves the type checking issue. However, it seems that currently only one Deno project is supported (or a single deno.json file must be shared between all projects in a monorepo).

[bcheidemann]

Since #21464 was recently shipped in Deno v1.39.0, the need for a new URL scheme is somewhat diminished. This is because Deno now supports "sloppy" Node style imports behind a flag. There are still some sharp edges but these can largely be worked around.