Merge deno_std into deno repo

[ry]

deno_std and deno have circular dependencies between them - and it's increasingly difficult as our codebase grows to keep them in sync.

I plan to merge the deno_std repo into deno in the near future.

I want to complete a few things first

• "cargo test" should be the main test runner deno#2933
• reorg directory structure deno#2852

[zekth]

Just a question, deno_std will still not be shipped with the deno runtime right?

[ry]

Correct - deno_std will still be available via https://Deno.land/std

This is just about being able to have CI testing both the std modules and internal code.

[zekth]

Also this move requires the review of current issues of the repo. Moving the related ones and closing the staling. (just to have it in consideration)

[dsseng]

Won't this cause longer and more frequent builds since CI will run both deno and deno_std tests for anything? So deno_std change will cause a CI run for both. Please pay attention to this.

[ry]

Yes, this will certainly increase the CI time for deno_std - it won't for deno.

We are moving to Github Actions in Deno - and that should improve the CI time... But yes, expect it to be about 15 minutes to get green.

The trade off is worth it. We need to have better understanding of how changes in core effect std and vise versa. Ultimately I think this merge will increase our agility.

[zekth]

Won't this cause longer and more frequent builds since CI will run both deno and deno_std tests for anything? So deno_std change will cause a CI run for both. Please pay attention to this.

Tests of deno_std are really fast so i'm not concerned with that. The only concern is the occurence of builds yes.

[keroxp]

Hmm... It must be hard task for contributors. I know there are some difficulties of managing parallel projects. But "all at once" is not good idea imo. On the first step, only modules depended by core repository should be moved, can you?

E.g. installer and prettier are pragmatically not part of std as a module. testing is special module and it is acceptable to have circular dependencies. And I think it is enough to run std's tests also in core's CI for checking compatibility of core/std.

[ry]

Now that we’ve moved CI to Github actions and it’s working well, we’ve started the transition
denoland/deno#3085

[zekth]

Also maybe a std tag github for the deno issues could be cool. To find if the issue / pr is related to core or std. Don't you think?