The issue with Deno Doc can't be sorted out currently due to JS resolvers using the standard ES modules, so things like import x from "a" won't work cause a is not a valid path, a.js is.

On the otherhand deno lint can be executed as a standalone binary and deno fmt is just an abstraction over a JavaScript formatting tool called dprint which is available as a standalone executable as well.

The real issue here would probably be the leveraging of the different formats of JavaScript across the ecosystems, and since I'm not a mantainer I can not speculate about whether those versions (such as CommonJS) will receive support at all in Deno tooling.

• Privatize std/datetime/formatter.ts to std/date/_format.ts.
• Privatize std/datetime/tokenizer.ts to std/date/_tokenize.ts.
• std/log: Rename LogRecord::datetime to LogRecord::date.

Closes #8594. <!-- Before submitting a PR, please read https://github.com/denoland/deno/blob/master/docs/contributing.md

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. -->

Context

1. Would like to leverage deno doc, deno fmt, deno lint agnostic of Deno projects.
2. Would like to be able to extend my own Rust CLI using the underline components from Deno

Intent

Would like to see Deno take some responsibility for bringing alignment around the JavaScript ecosystem by providing those CLI tools agnostic of Deno projects (as much as possible).

We are in the transition to leverage Deno for incoming projects over NodeJS, but realistically, we are not there yet, but we would like to stop the bikeshedding and misalignment around these tools, and be closer to "a way" to solve particular issues where freedom isn't that valuable, or in the worst case, would be much better to improve "a tool".

Thoughts

I am not that familiar with Rust, but it seems that the simple wrappers for the underline packages used in Deno CLI actually do some tedious stuff around matching files, and so on. Maybe keep raising the level of abstraction would be beneficial.

Also, I tried to use deno doc https://github.com/straw-hat-team/logger/blob/master/src/index.ts but didn't work

❯ deno doc ./src/index.ts
Cannot resolve module "file:///Users/ubi/Developer/StrawHat/logger/src/logger"

Also rename identifiers that have DateTime in them. The date-time object in JS is Date, we should match it. The module is heavily built on Date. DateTimeFormatter::format() accepts a Date.

Deno will always die on unhandled exceptions / rejections.

I'd like to request the ability to change this for uncaught promises.

I know a lot of people just say hey if this happens it is your fault. Technically your right. But this is reality. And people make mistakes. Production crashing because of a mistake is a serious issue. Especially when it is so easily preventable. But the problem really gets amplified when even if you are perfect, and your code catches everything and everyone, you can still crash if one of your deps forgets. So you can not just rely on yourself being perfect but the entirety of the world needing to be perfect. This in my opinion makes Deno very hard to want to use in production. Processes crashing are not an acceptable solution imo.

Let's take a look at a simple example. Please bare with me here.

In this example, what happens is the process crashes. Because the developer of that third party dep forgot to catch something. Now this could be god knows how many deps deep. So the argument that you have to check every line of your deps code isn't really possible realistically. Nor is having to check every single commit of every single dependecy. This just adds on to more reason of why Deno is impossible to use in production.

If this was nested some 10-15 levels deep, we would never be able to debug this and even attempt a fix.

This is all to say that Deno in production is really hard to vouch for. Realistically Deno is only usable in production if you do not use any deps for your projects.

Now for another point of view. Deno is realllllllly hard to use for beginners. A lot of users wanting to use my library are first time developers. This means they are just getting into their very first coding project EVER! I have made it as easy as possible for users like this to be able to get started. They can literally use the strictest TS settings without even needing to know a thing about typing or casting or anything. However, this 1 issue of them forgetting .catch is a serious issue.

Time and time again I have users reporting their processes crashing because they simply forgot to catch something. Not have a training wheel so to speak makes this really difficult. A simple handler to prevent crashes could be soooo useful because I could have this internally built for them so it alerts them of where they are forgetting to catch so that they can fix their code and prevent their processes from crashing.

Deno will always die on unhandled exceptions / rejections.

I'd like to request the ability to change this for uncaught promises.

I know a lot of people just say hey if this happens it is your fault. Technically your right. But this is reality. And people make mistakes. Production crashing because of a mistake is a serious issue. Especially when it is so easily preventable. But the problem really gets amplified when even if you are perfect, and your code catches everything and everyone, you can still crash if one of your deps forgets. So you can not just rely on yourself being perfect but the entirety of the world needing to be perfect. This in my opinion makes Deno very hard to want to use in production. Processes crashing are not an acceptable solution imo.

Let's take a look at a simple example. Please bare with me here.

In this example, what happens is the process crashes. Because the developer of that third party dep forgot to catch something. Now this could be god knows how many deps deep. So the argument that you have to check every line of your deps code isn't really possible realistically. Nor is having to check every single commit of every single dependecy. This just adds on to more reason of why Deno is impossible to use in production.

If this was nested some 10-15 levels deep, we would never be able to debug this and even attempt a fix.

This is all to say that Deno in production is really hard to vouch for. Realistically Deno is only usable in production if you do not use any deps for your projects.

Now for another point of view. Deno is realllllllly hard to use for beginners. A lot of users wanting to use my library are first time developers. This means they are just getting into their very first coding project EVER! I have made it as easy as possible for users like this to be able to get started. They can literally use the strictest TS settings without even needing to know a thing about typing or casting or anything. However, this 1 issue of them forgetting .catch is a serious issue.

Time and time again I have users reporting their processes crashing because they simply forgot to catch something. Not have a training wheel so to speak makes this really difficult. A simple handler to prevent crashes could be soooo useful because I could have this internally built for them so it alerts them of where they are forgetting to catch so that they can fix their code and prevent their processes from crashing.

Duplicate of #7013. Discussion of whether or not it should prevent crashes should be taken there, since it's not precluded by the issue title/description.

Deno will always die on unhandled exceptions / rejections.

I'd like to request the ability to change this for uncaught promises.

This issue is meant to showcase the need of this request by collecting and sharing all the times that processes unnecessarily crash due to no concern other than a forgotten .catch().

I know a lot of people just say hey if this happens it is your fault. Technically your right. But this is reality. And people make mistakes. Production crashing because of a mistake is a serious issue. Especially when it is so easily preventable. But the problem really gets amplified when even if you are perfect, and your code catches everything and everyone you can still crash if one of your deps forgets. So you can not just rely on yourself being perfect but the entirety of the world needing to be perfect. This in my opinion makes Deno very hard to want to use in production. Processes crashing are not an acceptable solution imo.

Let's take a look at a simple example. Please bare with me here.

In this example, what happens is the process crashes. Because the developer of that third party dep forgot to catch something. Now this could be god knows how many deps deep. So the argument that you have to check every line of your deps code isn't really possible realistically. Nor is having to check every single commit of every single dependecy. This just adds on to more reason of why Deno is impossible to use in production.

If this was nested some 10-15 levels deep, we would never be able to debug this and even attempt a fix.

This is all to say that Deno in production is really hard to vouch for. Realistically Deno is only usable in production if you do not use any deps for your projects.

Now for another point of view. Deno is realllllllly hard to use for beginners. A lot of users wanting to use my library are first time developers. This means they are just getting into their very first coding project EVER! I have made it as easy as possible for users like this to be able to get started. They can literally use the strictest TS settings without even needing to know a thing about typing or casting or anything. However, this 1 issue of them forgetting .catch is a serious issue.

Time and time again I have users reporting their processes crashing because they simply forgot to catch something. Not have a training wheel so to speak makes this really difficult. A simple handler to prevent crashes could be soooo useful because I could have this internally built for them so it alerts them of where they are forgetting to catch so that they can fix their code and prevent their processes from crashing.

VSCode fails to recognize import map ~/.import_map.json when I change it to /Users/alex/.import_map.json it works.

Is your feature request related to a problem? Please describe.

I would like to use same, universal location for import map config.

Describe the solution you'd like

Path with tilda should works.

I think integrating a more robust version of my webview module should suffice because abstractions and inventing new gui technologies is not really in the scope ... The web technologies are well established and using the platforms default provided browser...

How would you communicate between Deno and OS provided Webview? Would it be 2 separated contexts?

std/ws is a thing std/ws is a server, not a client. for client we have the web WS API.

Shouldn't this be in user land?

...

@balupton Is WebRTC not part of the standard browser interface? How would one implement this in userland?

std/ws is a thing so it probably could be user-land, however if it is it should be a std user land since this can be considered a standard interface.

I think integrating a more robust version of my webview module should suffice because abstractions and inventing new gui technologies is not really in the scope of the deno core or std (for example std/http only implements a basic web server without high level abstractions like routing). The web technologies are well established and using the platforms default provided browser does not add that much size to the executable unlike bundling something like chromium. Once webgpu lands and support for windowing (perhaps by using an external module like pane 😉) is added my hope is that one would be free to implement any new abstractions and ideas in their own modules, writing their own renderers, dsl, dom systems, etc.

just basics for creating a simple window

Honestly that wouldn't be enough for me : I need to build real apps, not macros.

That's why I said that we should include a simple way that has default assets basically and one like webview is right now. Fully html css and js

Sounds like a shortcut or alias can be made from that! @pierredewilde

In the meantime, you may use esbuild, an extremely fast JavaScript minifier written in Go, to minify your Deno bundles:

$ deno bundle https://deno.land/std@0.79.0/http/file_server.ts | esbuild --minify > file_server.min.js
$ deno run --allow-net --allow-read file_server.min.js

Other JavaScript minifiers (eg terser) may have issues like Unexpected character '#' - See https://github.com/terser/terser/issues/702

@bela53 I am experiencing a very similar message:

Could not load source '/path/to/workspace/std@0.79.0/_util/os.ts': Unable to retrieve source content.

☝️ This is always a reference to a remote module.

And I get a VS Code notification in the bottom right that reads:

This is a missing file path referenced by a sourcemap. Would you like to debug the compiled version instead?

with the options

• Always
• Always in this Workspace
• No
• Yes

It seems that I can just click the Continue button (looks like a play button or triangle) and the debug will continue to my first breakpoint successfully.

If it's helpful, this is my launch.json:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch Deno",
      "request": "launch",
      "type": "pwa-node",
      "program": "${file}",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect-brk",
        "--allow-all"
      ],
      "attachSimplePort": 9229
    }
  ]
}

I'm not sure what is causing this problem.

@bartlomieju Do you have any insight?

deno install --name <name> allow to specify the name of executable file.

Unfortunately, the name of running process is still deno eg Activity Monitor on Mac.

How can I change the process name, equivalent of process.title in Node.js ?

just basics for creating a simple window

Honestly that wouldn't be enough for me : I need to build real apps, not macros.

Not that it matters, but I also think that HTML/CSS/Web Standards are amazing. No need to reinvent the wheel.

I think that it would be nice to have a simple gui class aswell like autohotkey v2 has it. You just create a new gui like it's oop. It doesn't have to look good. But just basics for creating a simple window

Not that it matters, but I also think that HTML/CSS/Web Standards are amazing. No need to reinvent the wheel.

Closes #8412

test-with-decorators.ts

function A() {
  console.log("@A evaluated");
  return function (
    target: any,
    propertyKey: string,
    descriptor: PropertyDescriptor,
  ) {
    console.log("@A called");
    const fn = descriptor.value;
    descriptor.value = function() {
      console.log("fn() called from @A");
      fn();  
    };
  };
}

function B() {
  console.log("@B evaluated");
  return function (
    target: any,
    propertyKey: string,
    descriptor: PropertyDescriptor,
  ) {
    console.log("@B called");
    const fn = descriptor.value;
    descriptor.value = function() {
      console.log("fn() called from @B");
      fn();  
    };
  };
}

class C {
  @A()
  @B()
  static test() {
    console.log("C.test() called");
  }
}

C.test();

See the error as decorator A() isn't getting called (denopack uses Deno.transpileOnly() by default):

denopack -i test-with-decorators.ts -o bundle.js
denopack completed in 405ms
deno run bundle.js   
@A evaluated
@B evaluated
@B called
@B called
fn() called from @B
fn() called from @B
C.test() called

Expected behavior with deno run which uses Deno.compile():

deno run test-with-decorators.ts
@A evaluated
@B evaluated
@B called
@A called
fn() called from @A
fn() called from @B
C.test() called

This is the code Deno.transpileOnly() emits:

function _applyDecoratedDescriptor(target, property, decorators, descriptor, context) {
    var desc = {
    };
    Object.keys(descriptor).forEach(function(key) {
        desc[key] = descriptor[key];
    });
    desc.enumerable = !!desc.enumerable;
    desc.configurable = !!desc.configurable;
    if ("value" in desc || desc.initializer) {
        desc.writable = true;
    }
    desc = decorators.slice().reverse().reduce(function(desc, decorator) {
        return decorator(target, property, desc) || desc;
    }, desc);
    if (context && desc.initializer !== void 0) {
        desc.value = desc.initializer ? desc.initializer.call(context) : void 0;
        desc.initializer = undefined;
    }
    if (desc.initializer === void 0) {
        Object.defineProperty(target, property, desc);
        desc = null;
    }
    return desc;
}
var _class, _dec, _dec;
function A() {
    console.log("@A evaluated");
    return function(target, propertyKey, descriptor) {
        console.log("@A called");
        const fn = descriptor.value;
        descriptor.value = function() {
            console.log("fn() called from @A");
            fn();
        };
    };
}
function B() {
    console.log("@B evaluated");
    return function(target, propertyKey, descriptor) {
        console.log("@B called");
        const fn = descriptor.value;
        descriptor.value = function() {
            console.log("fn() called from @B");
            fn();
        };
    };
}
let C = ((_class = class C {
    static test() {
        console.log("C.test() called");
    }
}) || _class, _dec = A(), _dec = B(), _applyDecoratedDescriptor(_class, "test", [_dec, _dec], Object.getOwnPropertyDescriptor(_class, "test"), _class), _class);
C.test();

Obviously _dec will always take the last value (last decorator in chain) in the assignment above.

This will upload canaries before running tests, so canaries are uploaded regardless if the tests are flaky or not.

. If @jbergstroem wants to come forward and have his solution used, then I would be happy to oblige.

I context switched to other stuff and didn't follow up properly. Appreciate someone taking up the torch and crossing the goal line!

There were a total of 4 instances which need to be replaced when using the 1 Gb Ethernet MAC and UDP/IPv4 stack. After replacing them I was able to get traffic in both directions on my hardware. I will show how to replace them below for anyone else experiencing this problem:

axis_gmii_rx.v -> eth_crc_8: Replace with lfsr with the eth_crc_8 module

//lfsr #( // .LFSR_WIDTH(32), // .LFSR_POLY(32'h4c11db7), // .LFSR_CONFIG("GALOIS"), // .LFSR_FEED_FORWARD(0), // .REVERSE(1), // .DATA_WIDTH(8), // .STYLE("AUTO") //) //eth_crc_8 ( // .data_in(gmii_rxd_d4), // .state_in(crc_state), // .data_out(), // .state_out(crc_next) //);

// Old CRC logic used to get synthesis working eth_crc_8 eth_crc_8_inst ( .data_in(gmii_rxd_d4), .crc_state(crc_state), .crc_next(crc_next) );

axis_gmii_tx.v -> eth_crc_8: Replace with lfsr with the eth_crc_8 module

//lfsr #( // .LFSR_WIDTH(32), // .LFSR_POLY(32'h4c11db7), // .LFSR_CONFIG("GALOIS"), // .LFSR_FEED_FORWARD(0), // .REVERSE(1), // .DATA_WIDTH(8), // .STYLE("AUTO") //) //eth_crc_8 ( // .data_in(s_tdata_reg), // .state_in(crc_state), // .data_out(), // .state_out(crc_next) //);

// Old CRC logic used to get synthesis working eth_crc_8 eth_crc_8_inst ( .data_in(s_tdata_reg), .crc_state(crc_state), .crc_next(crc_next) );

arp_cache.v -> rd_hash and wr_hash: Replace with lfsr with the eth_crc_32 module

//lfsr #( // .LFSR_WIDTH(32), // .LFSR_POLY(32'h4c11db7), // .LFSR_CONFIG("GALOIS"), // .LFSR_FEED_FORWARD(0), // .REVERSE(1), // .DATA_WIDTH(32), // .STYLE("AUTO") //) //rd_hash ( // .data_in(query_request_ip), // .state_in(32'hffffffff), // .data_out(), // .state_out(query_request_hash) //);

// Old CRC logic used to get synthesis working eth_crc_32 rd_hash ( .data_in(query_request_ip), .crc_state(32'hffffffff), .crc_next(query_request_hash) );

//lfsr #( // .LFSR_WIDTH(32), // .LFSR_POLY(32'h4c11db7), // .LFSR_CONFIG("GALOIS"), // .LFSR_FEED_FORWARD(0), // .REVERSE(1), // .DATA_WIDTH(32), // .STYLE("AUTO") //) //wr_hash ( // .data_in(write_request_ip), // .state_in(32'hffffffff), // .data_out(), // .state_out(write_request_hash) //);

// Old CRC logic used to get synthesis working eth_crc_32 wr_hash ( .data_in(write_request_ip), .crc_state(32'hffffffff), .crc_next(write_request_hash) );