Umbrella issue for missing Deno features to enable this plugin to resolve url and npm specifiers

[bartlomieju]

Opening this issue so we can list all of missing features in Deno that are required to make this plugin work. We can link back to Deno repo issues to track the progress.

• "deno info --json" should contain cache path for npm packages denoland/deno#17168

[itsdouges]

Thanks mate! So I think remote imports should work pretty well currently (would love second eyes on the current implementation however). This is a good example of another implementation (for esbuild) for remote imports as well: https://github.com/lucacasonato/esbuild_deno_loader that I've been taking inspiration from.

For resolving npm specifiers we're going to need some work. Top of the list is:

• Resolving cache location for a npm specifier in deno info

From there we'll be unblocked to continue, one thing I'm unsure of is the complexity of resolving dependencies inside a npm specifier import. For remote (deno native) imports it's just iterate through the dependency array from deno info which is simple enough. Hopefully npm specifiers would be similar.

Other thoughts:

• It's possible to get the current deno exec with Deno.execPath(). Is there an API for getting the current import_map path? That would be useful to transparently pass it on without needing a config option for it.
• Should all modules try and be resolved through deno info? Currently the plugin only tries to resolve remote https imports.
• Only remote modules should be passed to deno cache, right? What happens if you pass local ones? Would that be appropriate for getting the emit location I guess? 🤔 Any benefit or just leave bundlers to it?
• How do we teach TypeScript/deno emit to use the Deno cache version of React? I'm hoping we could use the config and it would work as expected? E.g. in deno.jsonc:

  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "npm:react@18.2.0",
    "lib": ["dom", "dom.iterable", "dom.asynciterable", "deno.ns"],
    "types": ["vite/client"]
  }

[bartlomieju]

It's possible to get the current deno exec with Deno.execPath(). Is there an API for getting the current import_map path? That would be useful to transparently pass it on without needing a config option for it.

No, currently there's no way to get it - there are some issues asking to add it, but I'm a bit reluctant until this is agreed with WICG proposal.

Should all modules try and be resolved through deno info? Currently the plugin only tries to resolve remote https imports.

I think it makes sense, though there might be some edge cases where it's not desirable - I guess we will have to try and see if we come up with any situations where it's not desirable.

Only remote modules should be passed to deno cache, right? What happens if you pass local ones? Would that be appropriate for getting the emit location I guess? 🤔 Any benefit or just leave bundlers to it?

Not sure, local modules are only transpiled by Deno, but they are not cached (ie. the original source is always read from the specified local location).

How do we teach TypeScript/deno emit to use the Deno cache version of React? I'm hoping we could use the config and it would work as expected? E.g. in deno.jsonc:

I believe Deno uses react jsx transform by default, so it probably doesn't need any changes to work.

[itsdouges]

@bartlomieju Hey mate when working on resolving (cache + info) local modules it doesn't work if you try to import CSS modules, e.g:

This works, I can get an emit:
https://github.com/itsdouges/vite_deno_resolve/blob/13b9d58e8c67f7d1eb0d1cbbef1ff9e06a0cdb19/examples/url/local.tsx

import React, { useState } from 'https://esm.sh/react@18.2.0';
import { titleCase } from 'https://deno.land/x/case@2.1.1/mod.ts';

This doesn't work, as it imports CSS:
https://github.com/itsdouges/vite_deno_resolve/blob/13b9d58e8c67f7d1eb0d1cbbef1ff9e06a0cdb19/examples/url/main.tsx

import React from 'https://esm.sh/react@18.2.0';
import { createRoot } from 'https://esm.sh/react-dom@18.2.0/client';
import { App } from './local.tsx';
import './style.css';

Removing the import gets it working.

Would it be possible for Deno to noop this kinds of imports? So instead of throwing it just prints it out as is? This would allow us to get Deno to resolve local modules, and transform TypeScript to JavaScript (all with Deno! So less surprises with interop).

You can see a spike here https://github.com/itsdouges/vite_plugin_deno_resolve/compare/local-modules?expand=1 - currently has caching issues.

[bartlomieju]

Would it be possible for Deno to noop this kinds of imports? So instead of throwing it just prints it out as is? This would allow us to get Deno to resolve local modules, and transform TypeScript to JavaScript (all with Deno! So less surprises with interop).

Not really, that would break a lot of invariants Deno has about imports. There are two ways forward here - a) this import gets transpiled by Vite (which I believe Vite maintainers mentioned to me); b) we should work on adding CSS support to Deno (it would be a big endeavor though)

[itsdouges]

There are other static asset style imports that could exist in a frontend app though, such as images and fonts. Vite handling transpilation of local assets is definitely the way forward for now, but I imagine it'd make more sense to have it use the tsconfig from deno.json? Would be easy for some confusion to occur.

[bartlomieju]

But Node.js can't import those files either without them being transpiled into Js. I'm not sure I understand what tsconfig would be here. Could you elaborate?

[itsdouges]

Taking a step back - my assumption was Deno uses the config in deno.json for the transpilation from tsx -> js, so for example if I update compilerOptions.jsxImportSouce to "foo", then it imports jsx-runtime from the foo package instead of react. Is this a correct assumption?

If it is - then my point is that if Deno doesn't transpile local modules it'll be friction as there will be two or more configs for this now, one for Deno types, one for Vite transpilation. This wouldn't be worse than the current world in Node/Vite iirc but Deno has a chance here to really stream line it end to end.

If it isn't - how does it work?

[bartlomieju]

Ah yes, that's the case according to https://deno.land/manual@v1.29.1/advanced/jsx_dom/jsx#using-jsx-import-source-in-a-configuration-file. This can be also overridden via an import map. Maybe we could punt on it for now and get some basic example working that doesn't override this setting?