Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 21:36
    bartlomieju review_requested #4165
  • 21:36
    bartlomieju opened #4165
  • 21:24
    bartlomieju synchronize #4161
  • 21:13
    afinch7 commented #4149
  • 21:07
    bartlomieju synchronize #4164
  • 20:58
    bartlomieju synchronize #4161
  • 20:54

    denobot on gh-pages

    Update benchmarks (compare)

  • 20:47
    bartlomieju synchronize #4164
  • 20:42
    bartlomieju synchronize #4161
  • 20:39

    ry on master

    Return non-zero exit code on ma… (compare)

  • 20:39
    ry closed #4163
  • 20:39
    ry closed #4157
  • 20:36
    bartlomieju edited #4164
  • 20:32
    bartlomieju review_requested #4164
  • 20:32
    bartlomieju opened #4164
  • 20:28

    denobot on gh-pages

    Update benchmarks (compare)

  • 20:24

    denobot on gh-pages

    Update benchmarks (compare)

  • 20:15
    ry review_requested #4163
  • 20:12
    ry closed #4145
  • 20:12
    ry commented #4145
Joe Pea
@trusktr
In contrast, with export const foo = () => {}, the foo() function will not be available to be called unless the module where it came from has already been evaluated, otherwise you'll get the temporal dead zone error.
No prob. :)
If you have no circular dependencies though, then I don't see why not to use arrow functions as far as how the ES Module spec works. Maybe there's something Deno specific.
Joe Pea
@trusktr
One way to think of it is, if you concatenated all modules into one file (like Rollup bundler does), the vars and functions would hoist to the top of that file.
Baptiste Marchand
@baptistemarchand42_gitlab
The style guide also says "do not make circular imports", so I'm not sure if the arrow syntax rule is just a style preference or a deno specific thing.
either way, TIL about the TDZ!
Joe Pea
@trusktr

It might be just a guideline for ES Modules in general, that maybe Deno is promoting? Makes sense to do that I suppose.

Same with TypeScript: they have typed-language enthusiasts joining that community, with no experience in JavaScript, so its good to carry over general advice to them too, explaining the inherited foot guns.

Baptiste Marchand
@baptistemarchand42_gitlab
Is there anything like VError (https://github.com/joyent/node-verror) for deno? Couldn't find anything in the std or third party modules.
Kitson Kelly
@kitsonk
@baptistemarchand42_gitlab There is the DiagnosticItem structure, which is based off the TypeScript diagnostic structure which we somewhat normalize and integrate into the structures we use on the Rust side. There is Deno.formatDiagnostics() which is in master which will pass the structure to Rust and return a formatted string in line with what we would do internally. Runtime classes to construct those structures don't exist, but would be a great addition to std.
Joe Pea
@trusktr
Regarding the --config option, I see how it makes sense for a project's files. But what happens when it imports code from another project's .ts files (not declaration files) designed with a different tsconfig configuration?
Kitson Kelly
@kitsonk
you have to accomodate for the widest need, for example, Deno is strict by default, you might need to turn that off if you are consuming TypeScript that isn't strict. If you have a TypeScript file that uses experimental decorators, you have to turn it on. I can't think of an option that makes one TypeScript file work but breaks another.
If there is, raise an issue, and we would try to figure out how to deal with it, but it has always seemed like a YAGNI (you aren't gonna need it).
Joe Pea
@trusktr

As an example code without any strict modes will treat everything as nullable and not require type checks. Turning on strict would cause type errors to appear. As a project grows, has more dependencies, the more likely strict needs to be turned off for code that was made in non-strict modes.

I think the best solution (if it isn't too late) is for Deno to enforce pure strict mode and nothing less than that, so that we get the most type safety (and restrictions). I think it is better than people importing many projects and having to remove strict when they don't want to.

At the moment I happen to be working in a big project with all strict options turned off, and this project is just a mess. Turning on strict mode causes hundreds upon hundreds of errors that I don't have the time to fix at the moment.

It'd be nice for that never to happen in Deno, if that's something the community would be okay with (or more specifically if you and Ryan would be okay with that and willing to accept a subset of people also okay with the community that Deno caters to).

I can't imagine liking my Deno experience otherwise, unless I barely import any 3rd party libs, but that isn't scalable for a community.
Joe Pea
@trusktr

Deno is strict by default

If it isn't possible to enforce all Deno modules be strict, something interesting could be for packages published on deno.land/x (and std) that work in Deno with default settings to be marked with a prominent icon or label, making any packages that don't work in default strict mode seem less desirable.

Or maybe an ugly icon/label for packages that aren't strict. The website or Deno would need some way to be able to tell if a package follows full strictness (or Deno defaults).
Kitson Kelly
@kitsonk
Deno is strict by default. Forcing Deno to be strict and not allow/respecting a tsconfig.json makes no sense.
Kevin (Kun) "Kassimo" Qian
@kevinkassimo
I believe the problems with deno.land/x packages are that many of them are published long time ago, before we enforced "strict" in default tsconfig, which is a recent thing
Kitson Kelly
@kitsonk
we probably need a crawler that does some checking of things in deno.land/x, like strictness, that the redirect actually goes to something, etc.
Joe Pea
@trusktr
Users having to turn off strict modes to consume libraries (or just not use the libraries) is also undesirable. It's a circular problem.
So it seems like heavily promoting strict packages and making other packages otherwise look undesirable or outdated in the x UI might be a way to encourage people to use strict (default) settings.

I haven't tried deno yet, and am just hanging around, but we're so entrenched in regular TypeScript that it seems like there would be lots of hurdles migrating to Deno (if we ever did that).

Starting new Deno projects from scratch, with minimal dependencies, is much more feasible.

The nice thing about Node.js-TS ecosystem is that when relying on declarations, we don't care if a library was written with strict modes or not, but we can still force our own code to be strict.

Kevin (Kun) "Kassimo" Qian
@kevinkassimo
The last claim is not too different for Deno if the source code is under JS with a TS declaration file though
You are allowed to add type references to imports, or that things like Pika supports X-TypeScript-Types to implicitly provide declaration files for you
Joe Pea
@trusktr
true, in that case this problem is reduced if not totally gone, but Deno is designed to allow people to publish plain TypeScript (that's the nice part!).
Joe Pea
@trusktr

I see the http module prescribes using for await. But doesn't that mean that request are handled one by one, instead of in "parallel"?

But I think that requests must have to be arriving in order, ultimately, so maybe it isn't an issue, as long as there are no await statements inside the for await loop to handle the requests and therefore make them unintentionally not "parallel".

With NodeJS's callback-style of handling requests, the user can't inadvertently block the "loop" and make things "unparallel".
Joe Pea
@trusktr
So I suppose in Deno's case we need to actually think before sticking awaits in there.
// not parallel, bad
for await (const req of s) {
  const content = await getFileContent()
  req.respond({ body: content });
}

// parallel, good
for await (const req of s) {
  ~async function() {
    const content = await getFileContent()
    req.respond({ body: content });
  }()
}
Kurt Mackey
@mrkurt
for await still breaks my brain :D
Daniel Buckmaster
@crabmusket
@trusktr I think you're right, you can use your approach or getFileContent().then(...). When I've written Deno servers I've always kept as little code as possible inside the for await loop something like this:
for await (const req of s) {
  handle(req).then(res => req.respond(res));
}

async function handle(req) {
  let whatever = await whateverElse;
  ...
  return {...}
}
Andy Hayden
@hayd
You can also use listenAndServe
Kurt Mackey
@mrkurt
^^ just giving it a named function is how I do it :D
Mason
@maboesanman
what's the path format for running Deno fmt recursively on a directory
Mason
@maboesanman
turns out I'm an idiot. just used the zsh glob expansion instead
Daniel Buckmaster
@crabmusket
@hayd oh thanks, I didn't know that was a thing :sweat_smile:
earlin
@earlin
Hi, guys I would like to know if deno has some file watch functionality because I am used to ts-node-dev and would like to use it
Bartek Iwańczuk
@bartlomieju
we recently added fs watch API but it hasn't been yet released
that's a low level API though
earlin
@earlin
Great I will need that on my project at some point, but I am talking about the realtime compilation though because I am used to tsc -p -w, rollup -c -w, ts-node-dev main.ts, ...
Kyle June
@KyleJune
you would just use deno main.ts.
earlin
@earlin

in TypeScript compiler options website documentation (here) it says:

Run the compiler in watch mode. Watch input files and trigger recompilation on changes. The implementation of watching files and directories can be configured using environment variable. See configuring watch for more details.

This what I am talking about
deno main.ts just compiles and runs once, I have to do that repeatedly
for now I am using nodemon -x deno main --recompile but would love it if deno had it builtin

Sébastien GRAVIER
@IllusionPerdu
@earlin i think is deno --reload main.ts
Bartek Iwańczuk
@bartlomieju
deno --reload will reload cached file; there is no watch mode
earlin
@earlin
Ok thanks, I will use my hacky nodemon way, but is it planned tough or is out of scope ?
Ryan Dahl
@ry
@earlin file system events are coming in the next release - that doesn't add a "watch" feature exactly but it makes it very accessible to build one.
Joe Pea
@trusktr
@kitsonk Yeah, it'd be great to know at a glance on x/ which packages use full strict tsconfig settings or not (or "compliant" or not, or something).
@ry ^

It'd be even better if on a general level TypeScript supported .ts files for types, not just .d.ts declaration files. It currently does support .ts files to some degree, but sometimes you'll run into issues like microsoft/TypeScript#35744.

Without being able to consume .ts files, and only declaration files being official supported by TS, it is impossible to consume libraries that use all of TypeScript's language features.

Here's a more broad topic on that lack of functionality in declaration files: microsoft/TypeScript#35822

So the fact that Deno is designed for consuming .ts files (but that costs more compile time?) is nice because we can publish libraries that use any feature of TypeScript.