deno_dir reorg

[ry]

Currently my DENO_DIR looks like this

/Users/rld/.deno/
├── bin
│   └── deno
├── deno_history.txt
├── deps
│   ├── http
│   └── https
│       └── deno.land
│           └── x
│               ├── fs
│               │   ├── path
│               │   │   ├── constants.ts
│               │   │   ├── interface.ts
│               │   │   └── mod.ts
│               │   └── path.ts
│               ├── http
│               │   ├── file_server.ts
│               │   ├── http.ts
│               │   ├── http_status.ts
│               │   └── mod.ts
│               ├── io
│               │   ├── bufio.ts
│               │   └── util.ts
│               ├── media_types
│               │   ├── db_1.37.0.json
│               │   ├── deps.ts
│               │   └── mod.ts
│               ├── testing
│               │   └── mod.ts
│               └── textproto
│                   └── mod.ts
└── gen
    ├── 0021b0a2c686fac4019811b5c93189d5a9777de9.js
    ├── 0021b0a2c686fac4019811b5c93189d5a9777de9.js.map
    ├── 00962035aaaf777be1877911f2aa53c5c8af45bf.js
    ├── 00962035aaaf777be1877911f2aa53c5c8af45bf.js.map
    ├── 0d6e3626582696335cb96a79fdb9ec3f3bfa1331.js
    ├── 0d6e3626582696335cb96a79fdb9ec3f3bfa1331.js.map
    ├── 11bd9864a0cb45a60ba337fc688aba386f587a1f.js
    ├── 11bd9864a0cb45a60ba337fc688aba386f587a1f.js.map

Remote code is cached in ~/.deno/deps/https or ~/.deno/deps/http and generated javascript is stored under its content hash in ~/.deno/gen.

I think we should combine the generated and remote-cached directories so that the generated content lives belong the remote-cached typescript:

~/.deno/https/deno.land/x/fs/path.ts # cached from https://deno.land/x/fs/path.ts
~/.deno/https/deno.land/x/fs/path.js # generated
~/.deno/https/deno.land/x/fs/path.js.map # generated

This coincides better with how typescript normally operates

[kevinkassimo]

@ry this is potentially problematic if a user happens to have two files with the same name of different extensions. Adopting this design seems to go against the original argument of requiring extensions.

On the other hand, under our current design, if we are dropping hash from the filenames, are we adopting alternative approaches tell the versioning of source TypeScript code (i.e. some changes take place)?

[zzz6519003]

Out of this talk, do we have promise in Deno

[kevinkassimo]

@zzz6519003 Deno is built on top of V8 which includes support to native Promises years ago. Deno async API depends on Promises.

[ry]

@kevinkassimo People should not be using the same name with different extensions. I think it's fine to just exit and print a helpful warning.

Adopting this design seems to go against the original argument of requiring extensions.

I don't think so. The imports are still explicit.

The benefit of this design is so humans can inspect the DENO_DIR without the aid of software...

[kevinkassimo]

@ry I'm slightly worried that this basically poses extra restrictions on filenames from Deno that goes beyond the requirement of JavaScript itself. Personally I feel this counts as a prohibiting "magic" that is opposite of index.js but also troubling. Also, it is possible that people would do something like prettier.js as the implementation and uses prettier.ts to add type annotation wrappers on exported APIs...

As to inspections of the compiled code, we can probably instead add a flag on Deno that given a TypeScript file, (optionally compiles and) emits filenames that point to the code in $DENO_DIR/gen.

[ry]

@kevinkassimo Yeah... good point... I will think on it more.

[kevinkassimo]

@ry Random thoughts, I think another way we could redesign the layout of gen/ instead so that it mirrors the structure of deps/, which makes it also very easy to find the compiled output (but we still need to find some places to store the hashes)

[ry]

@kevinkassimo I think your idea of some tooling could work too... Something like this?

> deno info myfile.ts
compiled javascript: ~/.deno/gen/123513123123.js
source map: ~/.deno/gen/123513123123.js.map
>

[kevinkassimo]

@ry This design looks okay to me -- except that info might need to be a flag like --info or -I...

[kitsonk]

Sorry, I wasn't paying attention to this.

While we don't have it enabled again, if we do ever run JavaScript through the compiler to type check it, we would want to use what is emitted. For example you can put CommonJS or AMD modules in and get ESM out via the compiler.

One additional other thought, just so that we don't have to remap anything and could keep the output fine is:

~/.deno/https/deno.land/x/fs/path.ts # cached from https://deno.land/x/fs/path.ts
~/.deno/https/deno.land/x/fs/.gen/path.js # generated
~/.deno/https/deno.land/x/fs/.gen/path.js.map # generated

Then we wouldn't need to worry about any conflicts and it is still quite clear how the source and output files are related.

[bartlomieju]

Can we close this issue in favor of #2057?

[ry]

Yes - thanks