Bigger refactors

[ry]

• Further integration with module graph. A series of refactors to module loading that @bartlomieju is doing including refactor: rewrite TS dependency analysis in Rust #5029, refactor: TS compiler and module graph #5817, fix: TSX analysis in module graph loader #5785
  • Getting "error: Read-only file system" for .graph cache file #6080
  • error: Uncaught AssertionError: Unexpected skip of the emit. #6082
• set_slot / get_slot (use APIs added in Add safe alternative to get_data/set_data rusty_v8#360) refactor: Split isolate and state using safe get_slot() #5929
• op crates Op crate for Web APIs #6906
• rusty_v8 scopes refactor @piscisaureus Add (failing) test: escaping twice from EscapableHandleScope should panic rusty_v8#401 Various scope fixes and a failing test for an open bug rusty_v8#385 Use correct lifetime for TryCatch::exception()/message() return value rusty_v8#380 Make to_local() take a closure that returns a raw pointer rusty_v8#386 Scopes refactor rusty_v8#406
• port tools/http_server.py to rust Port tools/http_server.py to Rust, merge with hyper_hello #1453 chore: move redirect test server to rust #6364
• convert all code in cli/js to javascript. design doc. needs first to do experiments with snapshots and es modules in rusty_v8 Add module_snapshot test rusty_v8#396 Add failing es_snapshot test #6111 Port internal TS code to JS #6793

[nnajiabraham]

Hi Ryan, would love to contribute to Deno and looking at converting cli/js to JavaScript...
Will love a better explanation on what the expectation is here and how I can go about that? @ry

[nayeemrmn]

@nnajiabraham Follow discussion and links here: #4750. Not a good first issue, though.

[ry]

@nnajiabraham Thanks for the offer - any help is much appreciated. As @nayeemrmn said, this issue is for really involved long term projects. Have a look instead at the issues marked good-first-issue

[nnajiabraham]

Sure thing @ry will take a look at those

[yordis]

I hope you find a way to keep TypeScript.

It is really welcoming experience to open any file and figure out what the objects are without having to debug and relying on a strong understanding of all these objects in order to contribute (maybe add JSDoc everywhere?).

It is always a given and takes with typed languages but even languages like Erlang/Elixir require you to add types everywhere if you truly would like a broader range of people to contribute. Otherwise, only a few people will be able to; the rest will open issues and rely on those few people because we lack the understanding, and tools to even feel "confident" that we can give it a try (speaking from inside out).

😞

[CyriacBr]

I'm more worried about the message Deno is sending to the JS/TS community by removing TS from its internal.
Imagine building a runtime with TS first class support being one of the main selling point, then NOT actually using it in its internals. Kind of a do as i say not as i do story.

I hope @ry you realize how much influence you have on the JS community. The usage of TS internally should probably be reconsidered, or either properly addressed in a demystified official blog post of some sort.
Pretty sure people that supported Deno from the get go just for its TS features and for, indirectly pushing for TS usage more widely, are hella confused right now.

[Soremwar]

@CyriacBr

Imagine building a runtime with TS first class support being one of the main selling point, then NOT actually using it in its internals.

Well, most of the runtime isn't written in TypeScript either but that doesn't make it less useful for TS developers.

Typescript is a really nice tool for understanding what JavaScript is really doing behind curtains, but that convenience comes at a cost, and as discussed in the document, perhaps the advantages it might bring aren't worth the price in this case, and that's perfectly ok. And in your case and everyone else's that same question must be done at the moment of choosing the tool for building your application, everything comes at a cost.

I don't think replacing TypeScript in the internals will discourage the people of using it in the first place, and having a separate file with types as siggested in the document should keep dev experience on a similar level.

Not all tools are fit for all jobs, and building a runtime/compiler has more considerations than most applications, but don't let that stop you from using the great tool TypeScript is, specially after all the hard work that has been put into making Deno the great runtime it is now.

[ry]

@yordis @CyriacBr @Soremwar I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - very little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.

[teleclimber]

op crates @ry

Hey @ry, am I correct in assuming that refactor is to separate the Deno.* userland API handling from the cli project? If so 👍. I was just noticing that the CLI project includes all the rust and TS code that provides that API, which makes it harder to make a Deno-compatible runtime separate from CLI.

Thanks.

[getspooky]

hey @ry
I am working on the url module implementation, this module require a constants for example in order to Find first and last non-whitespace characters for trimming. A lot of constants that i need actually exists on std/path, I suggest to add _shared folder to glob all shared files across the deno std.
Thanks.

[tooolbox]

Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - very little of Deno is written in TypeScript.

This makes sense and I respect your judgement on this @ry

I noticed this in the design doc:

i considered stripping the types at build-time and using a unit test for the type check. unfortunately we don't have a good way to strip the types without spinning up TSC
also it doesn't solve the problem that TypeScript is getting in the way of producing the bundle we need, which is the main thing

I see swc is mentioned; wanted to comment that esbuild strips types and bundles, if that's of any interest.

Either way, good luck and thank you to the Deno team!

[ry]

Closing this issue because it's mostly complete.

op crates is still WIP - but I think it's time for a new roadmap.