suggestion: use main branch for Deno standard library module

[iuioiua]

Deno's standard library uses the canary release of the Deno runtime in CI. Doing so provides the benefit of catching early regressions that could be made in the Deno library by causing the CI to fail in the standard library.

However, this repo does not do the same back. Instead, this repo uses a version of the standard library a few versions back and has to be updated manually now and again. The pitfall of this method is that regressions can come up in the standard library that affects a "stable" version of the Deno runtime, affecting users.

I suggest that the Deno runtime repo instead uses the main branch of the standard library as its submodule. Doing so would shorten this feedback loop between the Deno runtime and standard library and catch cross-repo regressions before releases are published.

This is safe enough to do as long as PR merges are frozen when both repos versions are published, which I believe is the case. In other words, both repos end up using the release version code of each other even though they point to the other repo's main branch.

References:

• fix: revert "feat(node/cluster): cluster module for Node compat (#2271)" std#3111
• deno asks for NODE_CLUSTER_SCHED_POLICY every time on deno run #17414
• test(node): prevent leak of permission requirement std#3112

CC @kt3k

[kt3k]

Does git submodule has ability to track the remote 'branch'?

Doing so would shorten this feedback loop between the Deno runtime and standard library and catch cross-repo regressions before releases are published.

I think that shorter feedback is only necessary for std/node because only std/node is a part of CLI. Maybe we should set DENO_NODE_COMPAT_URL pointing main branch of std?

[bartlomieju]

I think that shorter feedback is only necessary for std/node because only std/node is a part of CLI. Maybe we should set DENO_NODE_COMPAT_URL pointing main branch of std?

AFAIK we can't do https://deno.land/std@main/ - also that means that this code would never update for users, unless they use --reload flag. I revived #16748 and it should be easier once #17264 lands.

[iuioiua]

Closing as a result of the work relating to denoland/std#3171.