Deno: Proposal: improve cache filenames

[brandonkal]

The current cache filenames and layout is unfortunate.

1. It breaks code navigation. Code for the Deno runtime can only be written in editors that implement the workarounds to locate the files.
2. The workarounds required are non-trivial for editors like vim.
3. Files are extension-less which breaks a lot of editors (no syntax highlighting, etc) such as VSCode.
4. Editor tab bars are rendered useless. Open these files for viewing in an editor and you have tabs with names like "b7953a2fe90b56defc2c4cbba3f7f8b963cf2a38e587d20c3ffcd11e95f4fb64"

https://github.com/denoland/deno/issues/4183

As I suggested in https://github.com/denoland/deno/issues/4069#issuecomment-592305083, the file names need to be more descriptive.

1. All cached files should have an extension. I would suggest TSX for compatibility.
2. The hash should be prefixed with a descriptive name.

The proposed filename format is:

"[stripped-file-basename]_[hash].[appended-extension-from-content-type]"

Example

yaml_b7953a2fe90b56defc2c4cbba3f7f8b963cf2a38e587d20c3ffcd11e95f4fb64.tsx

[axetroy]

This is back to the old question, what about special characters in the URL?

Files are extension-less which breaks a lot of editors (no syntax highlighting, etc) such as VSCode.

This requires the editor to support setting the language of this file manually (vscode-deno does just that)

Editor tab bars are rendered useless. Open these files for viewing in an editor and you have tabs with names like "b7953a2fe90b56defc2c4cbba3f7f8b963cf2a38e587d20c3ffcd11e95f4fb64"

I found this before and create an issue to vscode to support updating the title of the document

But it seems that the vscode team does not want to do this

currently, there is a temporary solution to show origin URL

The current cache layout may not be perfect, but it seems that this proposal is not better than the current one

[brandonkal]

I'm not sure how you arrived at that conclusion.

It's simple enough to add tsx to the end of a saved file and that would solve a lot of problems.

vscode-deno does not set the language when opening. Try opening any file in the cache directly to see what I mean. And that is specific to a VSCode extension. Adding a proper filetype extension would simplify everything.

Handling special characters is simple. You just strip them out. We just need the beginning of the filename to be English for editor tabs. The rest can be a hash.

[ianrumac]

Completely agree with this proposal.

The current way cache filenames are handled should really be improved, I don't see a reason not to add an extension. The current cache names impact the user experience a ton - no code navigation, no syntax higlighting - so if you haven't installed _the right plugin_ (out of a few with the same name) in _one of the few editors with deno plugins_, the fastest way to check what an interface offers is to:

• Cmd+click which opens deno.land in a browser
• If it's the file you want, great
• If not, open the folder link(hopefully)
• Search for the file you need
• Open it

So like, another app, a dozen clicks and a few network requests. Or you can grep for the file and open that, maybe that's faster if you alias it. For a fresh codebase that is going to be explored by a ton of people, this is a big issue.

But except the human experience, this impacts the machine experience too - the tooling. Any tooling that works with TS should now add a specific check if a metadata.json file exists so it can know those files are actually TS files and it's looking at deno cache.

Kinda feels like someone sold me a Ferrari with square tyres and said "well if you drive it fast, you wont't notice they're square"

Such a tiny change could improve the experience a lot.

Now, Re: Hashnames - I agree with that too - I'd go with [alphanumeric_character_only_name]_[hash].[extension].

This way special characters are eliminated, hashes are kept, splitting is easy and it's readable by everyone.