Hi!

Since this website has many different translations, it would be nice to have a routing for all translations?

Next.js provides a I18n feature by default: Internationalized Routing

Well cache does two things:

1. Download and cache remote urls
2. Transpile and optionally typecheck the given URLs

deno cache --watch would watch all local files in the given module graph, transpile and optionally typecheck them (2). It would not re-download & cache remote URLs.

@Skillz4Killz I guess you want deno cache --watch?

Yes, I think that would work. It was the first thing I tried but I think --watch doesn't work on cache. But as mentioned on Discord deno cache could be a confusing place for this. If you watch cache then you would be watching the downloaded files by Deno which are cached which as you can guess does not make any sense I do agree with them about this but I would take any solution for this because in my opinion this is a really neat feature when coding in TypeScript

@Skillz4Killz I guess you want deno cache --watch?

Even better: https://github.com/denoland/deno/pull/7382

https://github.com/denoland/deno/issues/2401#issuecomment-744563503

Hello 👋

I am hoping to request the ability to have something like tsc --watch. A method to be able to monitor all your files code to see if it would complete. Relying on an editor to tell you warnings only shows warnings in files you have open.

This is extremely useful in development and does not require having to continue deno run just to have it crash with errors so you can fix those and then run again just to crash again.

Use Case: Monitor that can easily show whether your code will or will not compile!

Thank you

@lucacasonato do you have any idea about this error? https://github.com/denoland/deno_lint/pull/632/checks?check_run_id=2058739263#step:17:307

Part of #330, #431

This PR does:

• rewrite with dprint_swc_ecma_ast_view
• refine the implementation to avoid false negatives
• add lots of tests (most come from ESLint)

It's not a CLI limitation. It's an ongoing problem with Rust's process::Command. Rust has the escape hatch of using the Win32 CreateProcess but Deno doesn't (and likely won't). The windows CreateProcess can take an arbitrary string, but Deno isn't set up to directly call the Win32 CreateProcess function.

And, yes, it's up to the target executable to interpret it, but any arbitrary command line string should be generable by the runtime.

This is definitely a problem when spawning child processes with arbitrary command lines on Windows. It is subtle and occurs as random command lines which panic with weird quoting errors (as the examples noted above). It's very problematic when trying to work around the windows cmd shell quoting quirks (which is needed for task runners; denox, devo, drake).

I'm not sure of the best course forward.

Blink intent to ship both import assertions and JSON modules. I assume this is aimed at Chromium 91/v8 9.1

Not sure if this was done on purpose, but the defaults for the extended and globstar options in path/glob/globToRegExpr...

https://github.com/denoland/deno_std/blob/27dcc84ae1fdafa32eb77a9ab2caaa768ccea2f6/path/glob.ts#L83

...and fs/expand_glob/expandGlob:

https://github.com/denoland/deno_std/blob/27dcc84ae1fdafa32eb77a9ab2caaa768ccea2f6/fs/expand_glob.ts#L79

...are the opposite. Perhaps it would be better to use the same defaults for both?

Extracted this bugfix from #9457.

In case JavaScript throws an unhandled error, part of the "shared_queue" could be still unprocessed. If this is the case; throw the js runtime error instead of asserting on the queue size not being 0.

I've verified that this test fails on main:

---- runtime::tests::shared_queue_not_empty_when_js_error stdout ----
thread 'runtime::tests::shared_queue_not_empty_when_js_error' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`', core/runtime.rs:1438:7
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@bartlomieju done

This commit makes the WebIDL input validation more robust.

This is really strange, i have tried to test it down.

I observed, see also the comments in the test file, that when you try to push messages via websocket.send using a normal ws connection, all works fine, also when you observe the websocket events for a ping, or a string, all works.

But when you use a wss connection, the messages will not be pushed. The problem seems to be the observing of the websocket events, if you remove/deactive it - all works, and the messages will be pushed to the client. Also, if u send a manual event to the server via a client, the not pushed messages, will then be pushed - seems the websocket server needs a trigger to actually push it. When u log the websocket connection you can see, that the messages are hanging in the message queue. :(

Expected Behaviour

Websocket messages will be pushed to client, when using a wss connection.

Actual Behaviour

No messages will be pushed.

Steps to Reproduce

1. Create a file named mod.ts with the following content:

 // ! Problem: When u use https message 2 and 3 will not be pushed, when the for loop is activated.

  const useHttps = true; // change me
  const observeWsEvents = true; // the problem seems to be here, change it to false when u use https and it works!

  async function handleWs(sock: WebSocket) {
    console.info("socket connected!");

    await sock.send("message 1");

    setTimeout(async () => {
      await sock.send("message 2");
      const cevent = new CustomEvent("cevent");
      globalThis.dispatchEvent(cevent);
    }, 1000 * 5);
    globalThis.addEventListener("cevent", async (event) => {
      await sock.send("message 3");
    });

    if (observeWsEvents) {
      for await (const event of sock) {
        if (typeof event === "string") {
          console.log(`ws:Text ${event}`);
          await sock.send(event);
        }
      }
    }
  }

  const port = 5000;
  const httpServer = useHttps
    ? serveTLS({
      port,
      certFile: "./cert/localhost.crt",
      keyFile: "./cert/localhost.key",
    })
    : serve({ port });

  console.info(`${useHttps ? "https" : "http"} server is running on :${port}`);

  for await (const req of httpServer) {
    try {
      const ws = await acceptWebSocket({
        conn: req.conn,
        bufReader: req.r,
        bufWriter: req.w,
        headers: req.headers,
      });
      console.info(`websocket server is running on :${port}`);
      await handleWs(ws);
    } catch (e) {
      console.error(`failed to accept websocket: ${e}`);
    }
  }

2. Run it with deno run --unstable --allow-read --allow-net --allow-env --lock-write --lock lock.json mod.ts
3. Inspect the websocket with something like: WebSocket Test Client

Using

• deno 1.6.3 (release, x86_64-unknown-linux-gnu)
• v8 8.8.294
• typescript 4.1.3

Build and install from source using [Cargo](https://crates.io/crates/deno):

Chrome canary:

I think we should just land for 1.9. Merge window opens on 17th right?

<!-- Before submitting a PR, please read http://deno.land/manual/contributing

1. Give the PR a descriptive title.

Examples of good title: - fix(std/http): Fix race condition in server - docs(console): Update docstrings - feat(doc): Handle nested reexports

Examples of bad title: - fix #7123 - update docs - fix bugs

2. Ensure there is a related issue and it is referenced in the PR text.
3. Ensure there are tests that cover the changes.
4. Ensure cargo test passes.
5. Ensure ./tools/format.js passes without changing files.
6. Ensure ./tools/lint.js passes. -->