astro file from the astro framework.
Currently you can’t really run this without the framework it lives in. There’s no
astro run example.astro command. Why would you need this? I’m using astro as an example, of a type of file that compiles to TypeScript, there are dozens,
dart, the list goes on. The same way you can’t just run this astro file, you can’t really run most of the others, some are framework specific, and some are language flavors. Even if they include a mechanism for execution there’s not a lot of interoperability. There’s also not a whole not of options when it comes to the runtimes and the package managers those runtimes use (npm for node, url imports for deno).
The way vite + npm works is fundamentally different from how deno url imports work. When a package such as
@reggi/astro-stuff has an astro file in its path
example.astro vite has access to this static file from the file system and can access it. In vite + deno what I want is this:
This is a astro file in a url import. Deno has no clue how to handle this type of file type, or the astro syntax. You can imagine that within the astro file, there may even be more deno imports and deno would need to know how to recursively get the dependencies.
The conversation on whether or not deno should handle this or userland should is active here.
Enter the ”
as-ts language server”. In deno you can specify import maps.
Then when you import a module you can do this:
The language server would be setup to take incoming local file requests or url requests fetch the file, cache and convert them into ts files. Deno would only see the ts file and if there are more imports deno would fetch those as well only seeing the ts files.
The server would be able to detect different file types