profile
viewpoint
Kitson Kelly kitsonk @ThoughtWorksInc Melbourne, Australia http://www.kitsonkelly.com/ Principal Technologist @ThoughtWorksInc, contributing to @denoland and author of @oakserver

issue commentmicrosoft/TypeScript

Offer option to resolve module path maps in emitted code

Also, if based on your first comment you expect paths to contained overloaded functionality, that would be a breaking change for a lot of other users of TypeScript who are trying to model what their runtime environment is looking like, the original intention of the poorly named paths argument (which was to model configurable loaders like AMD and SystemJS, and therefore copied the misleading name of such a configuration option there).

So you would need to propose introducing some sort of other variable that said "ignore the existing meaning of paths and resolve and rewrite the paths relative to something else", but also the feature would need to address where it isn't possible to express a relative path at runtime, and those who would need to mix runtime mapping and build time rewriting.

dannycochran

comment created time in 3 hours

issue commentmicrosoft/TypeScript

Offer option to resolve module path maps in emitted code

@dannycochran what rules should tsc follow to determine to rewrite?

# server/index.ts
import { foo } from '@common/helper';

Is the @ suggesting some sort of semantic meaning? That directly conflicts with Node.js resolution logic with namespaced packages. What would the tsconfig.json look like?

dannycochran

comment created time in 3 hours

issue commentmicrosoft/TypeScript

Same const symbols comparison does not compile

One could say it is a literal symbol, not a unique symbol.

hwanders

comment created time in 2 days

push eventkitsonk/deno

Bert Belder

commit sha 47c216317f8eb5bf277663a732a79f6b07ba79ef

build: enable 'derive' feature of 'serde' crate

view details

Ryan Dahl

commit sha bc467b265fbe06ace24f5d9536bd8eb36ae4a601

introduce JSON serialization for ops (#2799) Converts env(), exit(), execPath(), utime() and utimeSync() to use JSON instead of flatbuffers.

view details

push time in 2 days

push eventkitsonk/deno

Kitson Kelly

commit sha f0a235563e1eb748f4030d19af3f9a5ac59d2550

Support custom inspection of objects (#2791)

view details

Bartek Iwańczuk

commit sha 389763c04e3102d5b8261a10bb7514ba046fe373

bump test runner revision (#2800)

view details

Bartek Iwańczuk

commit sha b764d1b8ffc4bf5e2ab89bdbd978d708a6da0f24

fix: dynamic import panic (#2792)

view details

Ryan Dahl

commit sha bdc97b3976786bb744a27e59b0f4f28554a682df

Organize dispatch a bit (#2796) Just some clean up reorganization around flatbuffer/minimal dispatch code. This is prep for adding a JSON dispatcher.

view details

Kitson Kelly

commit sha 6c7d337960b3745a7b614a18150862279ef1c942

Support .d.ts files (#2746) Fixes #1432

view details

Bert Belder

commit sha 31aa7c1a5d8a27c720b6255dc3eceda3707b1826

build: support rust crates that generate sources in their build script

view details

Bert Belder

commit sha e0c1ed96e22dc9a94cb5457c8b3eb2f2cd1af831

build: remove per-crate 'treat_warnings_as_errors' gn flag

view details

Bert Belder

commit sha 7a902fed04e23c2be6133024f7ad8fdebb641c60

build: add 'cap_lints' flag for rust crates Using a specialized flag rather than the generic 'args' option makes build_extra/rust/BUILD.gn shorter and more readable.

view details

Bert Belder

commit sha 7f9c6decc8982dc9dec762d6f2cc77c6bdd3f817

third_party: upgrade rust crates

view details

Ryan Dahl

commit sha 0809b06a3938868f364f1343b0de4d5d9686495d

v0.16.0

view details

push time in 2 days

pull request commentdenoland/deno

Support .d.ts files

Thanks. Yeah I think it is best to iterate on it, even if we change the syntax. Hard to tell what we don't like. It may also struggle with some real world use cases which we can start to address.

I implemented a straight forward cache in the compiler that existed previously. I did it to help ensure once we had replaced a file we knew it. I suspect that had a side impact of reducing the threads that went back to Rust.

kitsonk

comment created time in 2 days

issue commentmicrosoft/TypeScript

Offer option to resolve module path maps in emitted code

If it is a different issue than the OP, who agreed it was a duplicate then open a new issue that isn't a duplicate that better describes the problem/proposal because it is a different issue...

dannycochran

comment created time in 3 days

issue commentmicrosoft/TypeScript

Offer option to resolve module path maps in emitted code

Some people need to learn to read.

The issue is closed because it is a duplicate. The original author indicated that they understood it as such. When the original author agrees it is a duplicate, it is a duplicate, no matter what you think and #16577 is still open people!

dannycochran

comment created time in 4 days

issue commentdenoland/deno

Allow scripts to be run with version flags

Yeah, we shouldn't do that.

dev-nicolaos

comment created time in 4 days

issue commentdenoland/deno

Rename Deno into deno

@ry it feels like we should either live with Deno which seems to be doing ok, or move to deno quickly.

Alexsey

comment created time in 5 days

Pull request review commentdenoland/deno

Support .d.ts files

 import { test, assertEquals } from "./deps.ts"; This design circumvents a plethora of complexity spawned by package management software, centralized code repositories, and superfluous file formats. +### Using external type definitions++Deno supports both JavaScript and TypeScript as first class languages at+runtime. This means it requires fully qualified module names, including the+extension (or a server providing the correct media type). In addition, Deno has+no "magical" module resolution.++The out of the box TypeScript compiler though relies on both extension-less+modules and the Node.js module resolution logic to apply types to JavaScript+modules.++In order to bridge this gap, Deno supports compiler hints that inform Deno the+location of `.d.ts` files and the JavaScript code they relate to. A compiler+hint looks like this:++```ts+// @deno-types="./foo.d.ts"+import * as foo from "./foo.js";+```++Where the hint effects the next `import` statement (or `export ... from`+statement) where the value of the `@deno-types` will be substituted at compile+time instead of the specified module. Like in the above example, the Deno+compiler will load `./foo.d.ts` instead of `./foo.js`. Deno will still load+`./foo.js` when it runs the program.++**Not all type definitions are supported.**++Deno will use the compiler hint to load the indicated `.d.ts` files, but some+`.d.ts` files contain unsupported features. Specifically, some `.d.ts` files+expect to be able to load or reference type definitions from other packages+using the module resolution logic. For example a type reference directive to+include `node`, expecting to resolve to some path like+`./node_modules/@types/node/index.d.ts`. Since this depends on non-relative+"magical" resolution, Deno cannot resolve this.++**Why not use the triple-slash type reference?**++The TypeScript compiler supports triple-slash directives, including a type+reference directive. If Deno used this, it would interfere with the behavior of+the TypeScript compiler.

If we used something that conflicted with TypeScript, we could remove it for Deno, but we would want it to be a noop everywhere else, otherwise we would have Deno only TypeScript.

Even for Deno, if it overlapped TypeScript syntax, we would need a way to disambiguate it, which I don't think would be easy, so we could use a triple-slash directive, but it would have to be something TypeScript currently ignores, so the following would be out:

/// <reference path="..." />
/// <reference types="..." />
/// <reference lib="..." />
/// <reference no-default-lib="true"/>

So something like this "could" work and would be terse enough:

/// <reference deno="..." />

The biggest "challenge" I see is that these are like include statements, and they effect the file they are in. What we need to support in Deno is something where certain statements are impacted, so they are external and their position matters. Because there is such a dramatic behaviour change, it maybe confusing.

kitsonk

comment created time in 5 days

push eventkitsonk/nocuous

Kitson Kelly

commit sha 5365c1546384a0942f5b7dbcb511d76ee9ed06ba

Remove /output

view details

Kitson Kelly

commit sha d83e8107f5ff198921fd39ef0684b2f4264832c9

Update dependencies

view details

push time in 6 days

issue commentdenoland/deno

perf: Dynamic imports

I don't think it is strictly a runtime thing. People would expect to consume modules in a type safe way, especially if they are TypeScript modules and enforce the checking. Just having V8 throw runtime errors, you would argue why have TypeScript at all then. Plus not every TypeScript error would be a JavaScript runtime error.

There should be no type direct emits in TypeScript. The emit should always be the same. The risk with transpileModule though is that it inherently doesn't catch all the errors that createProgram does.

bartlomieju

comment created time in 6 days

push eventkitsonk/deno

Nayeem Rahman

commit sha 11c850af423f07769f054c494a76cbd9efb8806c

Enforce permissions on kill(), homeDir() and execPath (#2723)

view details

Kevin (Kun) "Kassimo" Qian

commit sha ccee2f01ba2f6304720ab17e99dee17bf6687bd8

Implement Blob url support for worker (#2729)

view details

Kevin (Kun) "Kassimo" Qian

commit sha 4519f9a50db8852c5b70ff47481f0fc9d0fbe2f2

Make Deno.execPath a function (#2743) And throws without allow-env

view details

Kevin (Kun) "Kassimo" Qian

commit sha 77d0d1e45ccfd33a8a98e2f5fa4ba618759b5dd3

Fix small execPath issues (#2744)

view details

Ryan Dahl

commit sha 43d099c0275878f6c6358eb0e9a0094d076d7c29

Fix incremental 'cargo build' (#2740) Tip: RUSTC_WRAPPER should be unset for incremental builds to work.

view details

Bartek Iwańczuk

commit sha 5350abbc7ffdba6d17166fa00ad89e86979a43f7

manual: Edit note about V8 profiling (#2742)

view details

Ryan Dahl

commit sha e438ac2c74c823882dc9c9ecde2a9e9ed7bcfb4b

Add op_id throughout op API (#2734) Removes the magic number hack to switch between flatbuffers and the minimal dispatcher. Adds machinery to pass the op_id through the shared_queue.

view details

Daniel Buckmaster

commit sha 520bdb6c31dd08b6f4e52de5116fd23d6d57fdda

Fix repl crash when deno dir doesn't exist (#2727)

view details

andy finch

commit sha 56a82e72d9867a9b5f8a10bc8e4b81b86cd815c9

Resolve worker specifiers relative to main module of host. (#2751)

view details

Bert Belder

commit sha 6fbf2e96243e6b79c1fb03c17b376b028e442694

Dynamic import (#2516)

view details

Bert Belder

commit sha 83d5362f1d7d8589b862de57912135067a8278c7

v0.14.0

view details

Kevin (Kun) "Kassimo" Qian

commit sha 286ee1d8b68b54d39e698f3b78e3ce9e257fa674

Fix dynamic import base path problem for REPL and eval (#2757)

view details

Bartek Iwańczuk

commit sha 54982e948e882fbf413e06319f711d85b232026b

fix: cache paths on Windows are broken (#2760)

view details

Bartek Iwańczuk

commit sha 9bd473d8ac9228e483bd26028dbe7ba88e971c08

feat: print cache location when no arg in deno info (#2752)

view details

Bert Belder

commit sha c3afa557515c64610b23ee460f8c6251de421f1a

Propagate Url::to_file_path() errors instead of panicking (#2771) * Propagate Url::to_file_path() errors instead of panicking

view details

Nayeem Rahman

commit sha 1947f572d735096c1ccd7de2c386b8289c287701

Fix permission requirements for Deno.rename() and Deno.link() (#2737)

view details

Ryan Dahl

commit sha 1f8b1a587c397dd01e058820769580323a0f7330

Dynamic import should respect permissions (#2764)

view details

Ryan Dahl

commit sha 58f0e9b9b1b53ca486ef38ae662b98cbde839248

v0.15.0

view details

Bartek Iwańczuk

commit sha e6c349af9f7260c2c4ec713bd231fe554240721e

split up ops.rs (#2753) Note cli/dispatch_minimal.rs ops are not yet included in cli/ops. This is part of work towards #2730

view details

Ryan Dahl

commit sha 498f6ad431478f655b136782093e19e29248b24d

Remove dead code: legacy read/write ops (#2776) readSync and writeSync use dispatch_minimal now.

view details

push time in 6 days

issue commentdenoland/deno

Support for data URLs and object URLs

Here is the relevant discussion in Node.js: https://github.com/nodejs/node/pull/28614. There are some security concerns with allowing this, but I guess the same applies for doing it with web workers.

qwerasd205

comment created time in 6 days

push eventkitsonk/deno

Kitson Kelly

commit sha 55880193ee6c35fd6dc5063f9882fb14df690ce9

Support custom inspection of objects

view details

push time in 7 days

PR opened denoland/deno

Support custom inspection of objects

Resolves #2775

This PR adds support for custom inspection, introducing a symbol to allow it. For example, the following:

class Foo {
  [Deno.customInspect]() {
    return "bar";
  }
}

console.log(new Foo()); // logs `bar`

This will give users the ability to make inspection and logging more meaningful.

+27 -6

0 comment

4 changed files

pr created time in 7 days

create barnchkitsonk/deno

branch : console-custom-inspect

created branch time in 7 days

issue commentmicrosoft/TypeScript

Can't infer `void` from 0-arity function

It isn't working as you intended, but that doesn't mean it makes any sense to anyone else. Sorry.

goodmind

comment created time in 7 days

Pull request review commentdenoland/deno_std

JSDOM port

+import { jsdom as instance } from "./vendor/jsdom.js";+import { jsdom } from "./types/jsdom.ts";++export const JSDOM = instance.JSDOM as jsdom.JSDOM;

I suspect denoland/deno#2746 will fix this (or at least make it possible).

MarkTiedemann

comment created time in 8 days

created tagoakserver/oak

tagv2.3.0

A middleware framework for Deno's net server

created time in 8 days

push eventoakserver/oak

Kitson Kelly

commit sha e40e6b043d33e1c0827389a1335a9225548ce00a

Update to Deno 0.15

view details

push time in 8 days

issue commentdenoland/deno

perf: Dynamic imports

Requesting all potential imports makes sense when you are compiler a program with TypeScript, as it needs to ensure that all possible code would be valid, is transpiled, and doesn't have any type issues.

I'd expect TS compiler to have some kind of cache that it can request files from to avoid recompiling the same files again and again.

It kind of sort of does, but that is really up to the compiler host to implement. Previous versions of the compiler did have some sort of caching, but one of the problems is that TypeScript doesn't know what the "filename" of a module is until it calls resolveModules(), which in the case of Deno, returns the full module. TypeScript just keeps asking questions, and it is up for the host to figure out how to keep those questions efficient. If TypeScript knows that one module equals another and that is already in memory, it does cache the parse, etc... It just doesn't cache anything at the "host" level.

Also, when we moved from AMD to ESM in the compiler, we also moved from single file transpile to program transpile. This means that TypeScript now tries to resolve everything upfront. Going back to single file would mean that a module wouldn't need to be transpiled until it is requested from the runtime, but it does mean that lazily loading the compiler would need to be repeatedly done if there were lots of dynamic imports and if spun down, TypeScript would lose its state and likely have to request a whole new load of source files in order to do the compiling.

bartlomieju

comment created time in 8 days

push eventkitsonk/deno

Kitson Kelly

commit sha 51b93da7f6cf5fb24674186ceac170f9cdb16eed

Update manual to provide information about type definitions

view details

push time in 8 days

pull request commentdenoland/deno

[WIP] Support .d.ts files

@afinch7 that makes sense, and I don't know how I missed it. Currently we don't have an easy way to load stuff like this in Deno (nor do I think we should). With known things like TypeScript, it should be fairly easy to wrap it and have it be a ESM file. But in theory it is tangental to this PR. So we can now load the types, but we can't load the module.

Since really TypeScript should support output to ESM, I opened issue microsoft/TypeScript#32949 to request it.

kitsonk

comment created time in 8 days

issue openedmicrosoft/TypeScript

Provide TypeScript as an ESM

Search Terms

commonjs, esm, lib/typescript

Suggestion

Currently lib/typescript.js and other lib files do not support being loaded as ES modules. They only support loading as a global script or a CommonJS module.

Use Cases

For runtimes that want to load TypeScript as a module and not in the global namespace, they have to do some pre-processing using a packager like webpack, rollup, etc. to be able to load TypeScript as an ES Module.

In addition, there are useful CDNs like Pike which can parse npm packages, find the ES modules, and will host an optimised version designed for loading in greenfield modern/browsers.

Examples

For example, it is impossible to currently load lib/typescript.js in Deno as it only supports ESM and each import is assumed to be a module, and therefore the var ts is scoped to the module. Also loading directly as a module in a browser would be possible.

Checklist

My suggestion meets these guidelines:

  • [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • [X] This wouldn't change the runtime behavior of existing JavaScript code
  • [X] This could be implemented without emitting different JS based on the types of the expressions
  • [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • [X] This feature would agree with the rest of TypeScript's Design Goals.

created time in 8 days

push eventkitsonk/deno

Daniel Buckmaster

commit sha 520bdb6c31dd08b6f4e52de5116fd23d6d57fdda

Fix repl crash when deno dir doesn't exist (#2727)

view details

andy finch

commit sha 56a82e72d9867a9b5f8a10bc8e4b81b86cd815c9

Resolve worker specifiers relative to main module of host. (#2751)

view details

Bert Belder

commit sha 6fbf2e96243e6b79c1fb03c17b376b028e442694

Dynamic import (#2516)

view details

Bert Belder

commit sha 83d5362f1d7d8589b862de57912135067a8278c7

v0.14.0

view details

Kevin (Kun) "Kassimo" Qian

commit sha 286ee1d8b68b54d39e698f3b78e3ce9e257fa674

Fix dynamic import base path problem for REPL and eval (#2757)

view details

Bartek Iwańczuk

commit sha 54982e948e882fbf413e06319f711d85b232026b

fix: cache paths on Windows are broken (#2760)

view details

Bartek Iwańczuk

commit sha 9bd473d8ac9228e483bd26028dbe7ba88e971c08

feat: print cache location when no arg in deno info (#2752)

view details

Bert Belder

commit sha c3afa557515c64610b23ee460f8c6251de421f1a

Propagate Url::to_file_path() errors instead of panicking (#2771) * Propagate Url::to_file_path() errors instead of panicking

view details

Nayeem Rahman

commit sha 1947f572d735096c1ccd7de2c386b8289c287701

Fix permission requirements for Deno.rename() and Deno.link() (#2737)

view details

Ryan Dahl

commit sha 1f8b1a587c397dd01e058820769580323a0f7330

Dynamic import should respect permissions (#2764)

view details

Ryan Dahl

commit sha 58f0e9b9b1b53ca486ef38ae662b98cbde839248

v0.15.0

view details

Bartek Iwańczuk

commit sha e6c349af9f7260c2c4ec713bd231fe554240721e

split up ops.rs (#2753) Note cli/dispatch_minimal.rs ops are not yet included in cli/ops. This is part of work towards #2730

view details

Ryan Dahl

commit sha 498f6ad431478f655b136782093e19e29248b24d

Remove dead code: legacy read/write ops (#2776) readSync and writeSync use dispatch_minimal now.

view details

Bartek Iwańczuk

commit sha d2d3afaf2de3cc9709cdf145c2f9438d3a4fa8a1

add deno test subcommand (#2783)

view details

Nayeem Rahman

commit sha 52a66c2796f97f5a08d679389172c39c0652cb16

Fix import map panics, use import map's location as its base URL (#2770)

view details

Ryan Dahl

commit sha 81f809f2a675ff4ff7f93231ca87a18cb5b4628e

Revert "Remove dead code: legacy read/write ops" This is causing a segfault for unknown reasons - see #2787. This reverts commit 498f6ad431478f655b136782093e19e29248b24d.

view details

Yoshiya Hinosawa

commit sha 9aa9aafbab934b483977683e1ee430abb277833f

fix: set response.url (#2782)

view details

Bartek Iwańczuk

commit sha 1978358328e869a0e27c91dff848753437989382

chore: bump test runner version (#2784)

view details

Ryan Dahl

commit sha de713e42c8807e3124c9b5d418a69d2ea3460058

Upgrade to rust 1.37.0 (#2786)

view details

Kitson Kelly

commit sha 9789c9a0726a48375060575ee5d6029fb7775d16

Support .d.ts files

view details

push time in 8 days

issue commentdenoland/deno

Remote modules should not be able to import absolute local modules ("file:///")

In demos Ryan likes to show how you can run Deno scripts from the command line just by pasting a URL.

Yes, that is great, but again, like a browser, you design for no local file system information. Remote is all remote, local is local. Having remote have knowledge about local is bad design, and a huge security risk. This is why it is difficult if not impossible to access local files from remote code in browsers. If you have local "requirements" outside of Deno itself for remote code, it is bad design IMO. It totally breaks the value of "just typing a URL".

Having fixed paths, non-relative, is also bad design. It makes code not portable and fragile. It is like "you will only ever need 64kb of memory" type decisions.

ry

comment created time in 11 days

issue commentdenoland/deno

tsconfig.json with comments

Ah yeah, I forgot about that. I think we would need to do 1 then, and while it won't always be 100% accurate, someone would have to really screw things up and there are more likely to encounter a parse error in the compiler.

ConsoleTVs

comment created time in 12 days

issue commentdenoland/deno

Remove --no-prompt ... require users to explicitly prompt for permission

It sounds useful to allow code to determine how to interact if permissions aren't there, as in some permissions might be totally optional, and can be handled in code. I still think there might be a use case though where the user would just want to ensure no prompts are there, no matter what the code is. Like some container workloads, you absolutely don't want code to prompt and lock things, you just want the job to fail and exit.

ry

comment created time in 12 days

issue commentdenoland/deno

tsconfig.json with comments

The only thing we need it for in Rust land is to detect "checkJs": true to know to cache JavaScript modules return. The TypeScript compiler supports this (and needs to parse the files directly anyways). There are two solutions I see:

  • Just regex out the flag, which won't be 100% accurate, but really would be an edge case.
  • Not have Rust determine this flag directly and change the compiler API to report this flag back. Which might be better in the long term, if there are more options that Rust needs to understand.
ConsoleTVs

comment created time in 12 days

issue commentdenoland/deno

Remote modules should not be able to import absolute local modules ("file:///")

I think it is bad design for a remote module to ever expect a fixed local resource. If remote code needs configuration information, it should be resolved locally and passed. Tight coupling of remote modules to local resources just is begging for problems.

I can't see a good reason why remote modules would need the ability to import anything locally.

ry

comment created time in 12 days

issue commentdenoland/deno

Deno script can read any JSON file anywhere on computer without prompt

Or we disallow dynamic import of JSON, or we disallow root breaking for dynamic imports, or we put dynamic imports behind a flag.

teleclimber

comment created time in 13 days

pull request commentdenoland/deno

[WIP] Support .d.ts files

@ry so it works from this PRs perspective. The following:

Outputs:

$ deno --reload tests/type_definitions/typescript/main.ts
Compile file:///Users/kkelly/github/deno/tests/type_definitions/typescript/main.ts
Download https://unpkg.com/typescript@3.5.3/lib/typescript.d.ts
error TS2551: Property 'versions' does not exist on type 'typeof ts'. Did you mean 'version'?

► file:///Users/kkelly/github/deno/tests/type_definitions/typescript/main.ts:4:16

4 console.log(ts.versions);
                 ~~~~~~~~

  'version' is declared here.

    ► https://unpkg.com/typescript@3.5.3/lib/typescript.d.ts:19:11

    19     const version: string;
                 ~~~~~~~

But the way the typescript.js is formed, nothing gets exported as the module, so Deno loads it, but we get an empty object returned back. Looking at the script, I am a little confused how it works at all, under node or rollup. It is a global script that creates a var ts variable (plus a couple others) and runs it through a series of IIFE. I am not sure how it "exports" anything. 😕

kitsonk

comment created time in 15 days

pull request commentdenoland/deno

[WIP] Support .d.ts files

Are you able to load the TS compiler with this?

That is my next use case to test.

kitsonk

comment created time in 16 days

pull request commentdenoland/deno

[WIP] Support .d.ts files

Ok, I have tested now with lodash-es but using the types from @types/lodash and that appears to be all working:

// @deno-types="https://unpkg.com/@types/lodash@4.14.136/index.d.ts"
import * as _ from "https://unpkg.com/lodash-es@4.17.15/lodash.js";

console.log(_.add(1, 2));

The change I made is that the hint only applies to the next import/export statement. My original thought would be that we might have several imports in a row and that we would resolve the type definition for each on based on a path, but that doesn't make a lot of sense in practice.

We still won't be able to support all type definitions at the moment, since some try to import or reference types from other type libraries. (e.g. /// <reference types="node" />). Because we don't magically resolve them, we don't know where to look. Right now they simply get passed upstream and Rust complains about not being able to resolve the module, but provides a cryptic message. I want to catch those earlier and have something more meaningful.

kitsonk

comment created time in 17 days

push eventkitsonk/deno

Nayeem Rahman

commit sha 11c850af423f07769f054c494a76cbd9efb8806c

Enforce permissions on kill(), homeDir() and execPath (#2723)

view details

Kevin (Kun) "Kassimo" Qian

commit sha ccee2f01ba2f6304720ab17e99dee17bf6687bd8

Implement Blob url support for worker (#2729)

view details

Kevin (Kun) "Kassimo" Qian

commit sha 4519f9a50db8852c5b70ff47481f0fc9d0fbe2f2

Make Deno.execPath a function (#2743) And throws without allow-env

view details

Kevin (Kun) "Kassimo" Qian

commit sha 77d0d1e45ccfd33a8a98e2f5fa4ba618759b5dd3

Fix small execPath issues (#2744)

view details

Ryan Dahl

commit sha 43d099c0275878f6c6358eb0e9a0094d076d7c29

Fix incremental 'cargo build' (#2740) Tip: RUSTC_WRAPPER should be unset for incremental builds to work.

view details

Bartek Iwańczuk

commit sha 5350abbc7ffdba6d17166fa00ad89e86979a43f7

manual: Edit note about V8 profiling (#2742)

view details

Ryan Dahl

commit sha e438ac2c74c823882dc9c9ecde2a9e9ed7bcfb4b

Add op_id throughout op API (#2734) Removes the magic number hack to switch between flatbuffers and the minimal dispatcher. Adds machinery to pass the op_id through the shared_queue.

view details

Kitson Kelly

commit sha 606fe2a1926d87ef5f5d1f80724bfa367b389d84

[WIP] Support .d.ts files Fixes #1432

view details

push time in 17 days

issue commentdenoland/deno

Intl.NumberFormat Error is Preventing a jQuery Replacement

Duplicate of #1968 we need to add some version of the ICU for Intl to be available.

Lonniebiz

comment created time in 17 days

pull request commentdenoland/deno

[WIP] Support .d.ts files

Ok, so my working branch, this now works:

// @deno-types="https://unpkg.com/dayjs@1.8.15/index.d.ts"
import dayjs from "https://unpkg.com/dayjs@1.8.15/esm/index.js";

const date = dayjs();
console.log(date.seconds());

Which has an error (the API is second(), not seconds()), so it now outputs:

Compile file:///Users/kkelly/github/deno/tests/type_definitions/remote/main.ts
Download https://unpkg.com/dayjs@1.8.15/index.d.ts
error TS2551: Property 'seconds' does not exist on type 'Dayjs'. Did you mean 'second'?

► file:///Users/kkelly/github/deno/tests/type_definitions/remote/main.ts:5:18

5 console.log(date.seconds());
                   ~~~~~~~

  'second' is declared here.

    ► https://unpkg.com/dayjs@1.8.15/index.d.ts:46:5

    46     second(): number
           ~~~~~~

Fixing it then outputs:

Compile file:///Users/kkelly/github/deno/tests/type_definitions/remote/main.ts
Download https://unpkg.com/dayjs@1.8.15/index.d.ts
Download https://unpkg.com/dayjs@1.8.15/esm/index.js
Download https://unpkg.com/dayjs@1.8.15/esm/constant
Download https://unpkg.com/dayjs@1.8.15/esm/utils
Download https://unpkg.com/dayjs@1.8.15/esm/locale/en
Download https://unpkg.com/dayjs@1.8.15/esm/constant.js
Download https://unpkg.com/dayjs@1.8.15/esm/utils.js
Download https://unpkg.com/dayjs@1.8.15/esm/locale/en.js
32

Getting excited... The other part I need to do though is that if the value of the directive looks like a directory to resolve the .d.ts files relative to that directory, in order to support UMD type definitions (where each module has its own .d.ts file).

kitsonk

comment created time in 17 days

Pull request review commentdenoland/deno

[WIP] Support .d.ts files

+/// <deno-types path="./foo.d.ts" />+import * as foo from "./foo.js";++/// <deno-types path="./bar.d.ts" />+import * as bar from "./bar.js";

Sort of...

From the TypeScript documentation:

For example, including /// <reference types="node" /> in a declaration file declares that this file uses names declared in @types/node/index.d.ts; and thus, this package needs to be included in the compilation along with the declaration file.

It is more of a directive for .d.ts files to say "I also need these types" and relies upon the "magical" resolution within node_modules. We might actually have a bit of a problem with that now that you mention it, but at least this would be a step forward and we can figure out how to address that in the future.

I agree it does look funny, the only other suggestion, is that there are a couple TypeScript compiler "hints" like @ts-check and @ts-nocheck and @ts-ignore. A "hint" style syntax might work which could be something like:

// @deno-types="https://unpkg.com/@types/foo@~1.0.0/index.d.ts"
import * as foo from "https://unpkg.com/foo@~1.0.0/index.js";
kitsonk

comment created time in 17 days

Pull request review commentdenoland/deno

[WIP] Support .d.ts files

+/// <deno-types path="./foo.d.ts" />+import * as foo from "./foo.js";++/// <deno-types path="./bar.d.ts" />+import * as bar from "./bar.js";

That assumes you have control of bar.js which I didn't think would be a common workload. Also, in order for the compiler to see that it has to resolve and load the .js file. In this case, the .js file is never loaded by the compiler, the .d.ts is instead to give TypeScript the types.

The typical use case is going to be, in my opinion, "I am using an external library named "foo", that library has types at @types/foo, I want to use that library in Deno, but I also want that code to work other places". I will write something like this, likely in something like deps.ts:

//# types=https://unpkg.com/@types/foo@~1.0.0/index.d.ts
import * as foo from "https://unpkg.com/foo@~1.0.0/index.js";

If you have mixed mode Deno project though, you don't need this feature, as allowJs is on by default, which allows you to resolve .js files and import them into Deno, and then checkJs would allow you to type check the files based on the JavaScript itself, plus and JSDoc comments. (I also believe // @ts-check in each JavaScript file would also work, though I haven't tested it).

kitsonk

comment created time in 17 days

push eventkitsonk/deno

Kitson Kelly

commit sha deb492a956759b058fb1d2e688c2cc07c074edea

Fix issue with caching source files

view details

push time in 18 days

PR opened denoland/deno

[WIP] Support .d.ts files

Fixes #1432

I have a MVP where the following is working:

/// <deno-types path="./foo.d.ts" />
import * as foo from "./foo.js";

/// <deno-types path="./bar.d.ts" />
import * as bar from "./bar.js";

console.log(foo.foo, bar.bar);

Where instead of TypeScript trying to load foo.js and bar.js, it instead loads foo.d.ts and bar.d.ts. There are quite a few more scenarios that need to be supported and I need to try it out with some real world code, but it looks like it will work.

+143 -20

0 comment

8 changed files

pr created time in 18 days

create barnchkitsonk/deno

branch : support-dts

created branch time in 18 days

push eventkitsonk/deno

Nayeem Rahman

commit sha ef63ec763a142f1e96e12e21d27ffae439f84ffd

Makes shebang Linux compatible (#2694)

view details

Bartek Iwańczuk

commit sha 421cbd39b4f0fdbdfc2eeed6da8dd3410246a044

factor out FileFetcher to separate module (#2683) * merge SourceFileFetcher trait and FileFetcher struct * move logic related to source file fetching to //cli/file_fetcher.rs * use Result when creating new ThreadSafeState

view details

Bartek Iwańczuk

commit sha e7cee29c849286f9b492eb404634a0387b9a75a0

Add --current-thread flag (#2702)

view details

Bartek Iwańczuk

commit sha 2e1ab8232156a23afd22834c1e707fb3403c0db6

refactor: cleanup compiler pipeline (#2686) * remove fetch_source_file_and_maybe_compile_async and replace it with State.fetch_compiled_module * remove SourceFile.js_source() * introduce CompiledModule which is basically the same as deno::SourceInfo and represents arbitrary file that has been compiled to JS module * introduce //cli/compilers module containing all compilers * introduce JsCompiler which is a no-op compiler - output is the same as input, no compilation takes place - it is used for MediaType::JavaScript and MediaType::Unknown * introduce JsonCompiler that wraps JSON in default export * support JS-to-JS compilation using checkJs

view details

Ryan Dahl

commit sha b3541c38f5672ffb4a29d66dca19d88b9ecae478

v0.13.0

view details

Ryan Dahl

commit sha 3971dcfe10b94e901a224b5328a9dafd1e2ecc08

Use system rustfmt instead of fixed binary (#2701)

view details

Tomohito Nakayama

commit sha deec1b9b97011d1a0ef7312c0a3efde21186b82d

Implement function convertLineEndingsToNative in blob.ts (#2695) based on https://w3c.github.io/FileAPI/#convert-line-endings-to-native

view details

Bert Belder

commit sha 5bca001f9703940e693d6a55944ef1ee7fc67f58

build: support crate imports using an alias name A crate can assign an alternative name, different from the crate name, when importing another crate. On the command line this looks like: rustc ... --extern foo_crate=path/to/bar_crate.rlib We need to support this so we can eventually upgrade to rand-0.7.x.

view details

Bert Belder

commit sha c6861b537ead4bba21817610664d68ffbe7daad5

third_party: upgrade rust crates

view details

Kevin (Kun) "Kassimo" Qian

commit sha 52c13fb3ed94e41d90bbe08d1bc299ca90505755

Enforce env permission on homeDir() and execPath (#2714)

view details

Bartek Iwańczuk

commit sha aaa7a3eac4df0de9a93dc8fc4717d38212a3de5b

use BTreeMap for ResourceTable (#2721)

view details

Kevin (Kun) "Kassimo" Qian

commit sha ddee2dff14772ade16e282ad18eda6f5054ce94e

Provide option to delete Deno namespace in worker (#2717)

view details

Ryan Dahl

commit sha a517513182221aa351528cf15d28c449b49fea13

Remove Deno.build.args feature (#2728) This is a minor feature which complicates the build signifigantly. Removing to ease refactoring the build system: https://github.com/denoland/deno/issues/2608

view details

Ryan Dahl

commit sha 046cccfe1768837fcd5b4c1fd7d52fb2d98c0b11

Remove dispatch optimization (#2732) Deno.core.dispatch() used to push the "control" buf onto the shared array buffer before calling into V8, with the idea that it was one less argument to parse. Turns out there is no more overhead passing the control ArrayBuffer directly over. Furthermore this optimization was making the refactors outlined in #2730 more complex. Therefore it is being removed.

view details

push time in 19 days

issue commentdenoland/deno

Support d.ts files

Actually I was wrong, they are in the AST, if they are "known" directives. Why I didn't see it before was using the suggested text, which doesn't get parsed. Also they aren't part of the AST, as they are attributes on the SourceFile which is the root of the AST.

So basically, anything that doesn't comply with a supported directive just looks like a comment. Also, my previous concern about when the AST would be available, and the need to "refresh" after we really resolved to model. I think the best thing to do at this point is to ensure the code is properly abstracted out, so that if we can somehow get that information from the AST in the future we would just need to change a method or two, but utilise RegEx for now (using some form of triple slash directive).

reggi

comment created time in 19 days

issue commentdenoland/deno

Support d.ts files

/// <reference denotypes="./foo.d.ts" />

There are more directives than reference and that might work, but I wouldn't want to interfere with a known directive. I would suggest something like:

/// <deno-types path="./foo.d.ts" />

Are these in the AST?

A quick check says no, they are like other trivia, related to the next nearest node, but that seems a bit strange... I need to do more research and see that while they may not be in the AST, if there is another API the surfaces up triple-slash directives. I suspect there must be.

reggi

comment created time in 19 days

push eventkitsonk/nocuous

Kitson Kelly

commit sha 5045949fadc9fc1953e044e6f257eb0281fea847

Flesh out more tests.

view details

push time in 19 days

issue commentdenoland/deno

Support d.ts files

Maybe I'm betraying my ignorance of typescript, but what about using /// <reference types="./foo.d.ts" /> ?

That would be covered by point 1:

This means it needs to be something ignored by other runtimes where it is expected they would either resolve the types independently or simply not enforce the type checking on the external JavaScript.

The way we need to interpret the triple slash directive is different than the way tsc would need to do it, and so we would likely "break" the way it works. That is just an educated assumption at this point, one I should prove when tackling this problem, but I am pretty certain it will break.

It would be good if this could be done as part of the checkJs compilation (i.e. actually look for it in the AST provided by TS). I suppose a regex across the file is probably not measurably slow tho - so that might work for a first pass.

I thought about that, the biggest problem is that trivia (comments) are not part of the AST in TypeScript. You basically have visit the node and then query if there is trivia. Even then I would have concerns that we would have to reparse each file, because you don't get back the AST until the parse happens, which requires all imports to be resolved. So we would parse the AST, load additional .d.ts files and then have to reparse the AST. I don't think the raw, just syntax, parse is available easily.

reggi

comment created time in 19 days

issue commentdenoland/deno

Support d.ts files

I have been thinking about this a fair amount. Proposing the following solution, which I plan to start working on. The solution needs to have the following features:

  • Be compatible with tsc and other TypeScript compilers. This means it needs to be something ignored by other runtimes where it is expected they would either resolve the types independently or simply not enforce the type checking on the external JavaScript. This also means that we can't use "real" syntax, so something like import from "something.d.ts" will not be possible.
  • Be declarative. In order to avoid "magic" lookups or complex resolution logic, applying types should be explicit, not implicit.
  • Support local and remote .d.ts files, just like we support local and remote modules.
  • Support both UMD and ambient type declarations. For UMD, this means supporting a path where each sub module is attempted to be resolved.
  • Be able to be applied "externally". Since the use case will be importing external JavaScript libraries into a Deno TypeScript programme, the declarative directives will need to be applied before the import (and therefore module resolution).

So based on these constraints/requirements, I propose the following:

  • Introduce a comment pragma of typeDefinition which will be applied to the next import statement. Specifically the following syntax: //# typeDefinition="foo.d.ts".
  • If the value ends in .d.ts it is considered either an ambient declaration file, or a UMD file applied only to that specific module. If the value ends with anything else, it will be considered a path and the following module will be resolved by using that as the root.

To make this work, I think this is what I need to build:

  • Whenever a new module is loaded by the compiler, the compiler will need to parse out the comment pragmas. When it identifies a comment pragma, it will need to parse out the next import statement.
  • The compiler will need to maintain a map of imports to pragmas.
  • When the compiler then attempts to resolve the module names, it will need to use the map to resolve to a .d.ts file instead of a JavaScript file.

I believe then that TypeScript will simply utilise the resolved .d.ts files to provide type information for the program, and not touch the underlying JavaScript. When the program is emitted, any "raw" JavaScript will be missing, but I believe as Deno starts loading the modules into runtime, any missing "raw" JavaScript will be automatically resolved and loaded.

reggi

comment created time in 19 days

issue commentdenoland/deno

v8 change to QuickJS

Also, while QuickJS is quicker than some of the other embeddable engines like DuckTape, it isn't faster than V8 for most common workloads, because of lack of the JIT as well as other optimisations. V8 has a huge team of people behind it, taking real world workloads and tuning them. QuickJS can't ever compete with that. Of course if you have an IoT device, I would certainly consider basing it off of QuickJS.

ChasLui

comment created time in 21 days

issue commentdenoland/deno

Support top-level await

The TypeScript team are indicating that it will be challenging to downemit and are considering not allowing a downemit. That is find from our perspective, but that "problem" continues to delay them addressing the issue.

ry

comment created time in 21 days

issue openeddenoland/deno

assert and CFA

Tracking issue.

After originally indicating it was a design limitation, the TypeScript team revisited allowing the ability to model type narrowing via assert(). The assert() pattern is heavily used within Deno and once microsoft/TypeScript#32695 is landed is part of a TypeScript release we will be able to make all of our code more sound.

created time in 21 days

fork kitsonk/rollup-plugin-typescript2

Rollup plugin for typescript with compiler errors.

fork in 22 days

push eventkitsonk/oak

Kitson Kelly

commit sha 329dc96fefd58e1f9ec43edd6920afdc3d55c417

Update CI to Deno v0.13

view details

push time in 23 days

push eventoakserver/oak

Kitson Kelly

commit sha 329dc96fefd58e1f9ec43edd6920afdc3d55c417

Update CI to Deno v0.13

view details

push time in 23 days

issue commentmicrosoft/TypeScript

files are not scoped if they don't contain at least one export or import statement

You could say that this is NodeJS not abiding by the JS spec

Correct. There are Scripts and Modules in the specification. Of course Node.js had its behaviour well before there were modules in the specification.

I don't really understand the reasons against adding a tsconfig.json option to assume files are modules.

My response was specifically to the suggestion of "Is it necessary that non-module ts files be compiled to a shared global scope?" The answer to that is yes. Because there is a difference between a Script and a Module in the language specification, and there are expectations about how it is interpreted. The current behaviour, IMO, is appropriate and valid, and I linked to the JavaScript proposal that this is a JavaScript problem as well.

As far as a flag, well I generally see that as being useless, because the current pattern of export {} is effective and as opt-in as a flag would be, but that isn't in itself a reason. The compelling reason in my mind is why should TypeScript come up with a unique solution, when there is a proposed solution for JavaScript and a current effective workaround.

Hotell

comment created time in 23 days

Pull request review commentdenoland/deno

WIP Add test for #2703 ...

 void deno_init() {     // remove this to make it work asynchronously too. But that requires getting     // PumpMessageLoop and RunMicrotasks setup correctly.     // See https://github.com/denoland/deno/issues/2544-    const char* argv[2] = {"", "--no-wasm-async-compilation"};-    int argc = 2;+    const char* argv[3] = {"", "--no-wasm-async-compilation", "--async-stack-traces"};

I think they have to be collected via other APIs 😢 see: https://github.com/nodejs/node/issues/11865#issuecomment-288450455

ry

comment created time in 23 days

issue commentmicrosoft/TypeScript

files are not scoped if they don't contain at least one export or import statement

Is it necessary that non-module ts files be compiled to a shared global scope?

That is the only logical conclusion to come to, as that is how JavaScript is evaluated when it isn't a module.

There is a TC39 proposal, Stage 1, that address this concern in JavaScript/ECMAScript: https://github.com/tc39/proposal-modules-pragma. I don't know how active it is and what sort of support it has, but clearly it isn't a "TypeScript" problem as much as it is a "JavaScript" problem.

Hotell

comment created time in 23 days

issue commentdenoland/deno

Order of CLI flags

We have to have some sort of demarkation between what is to be consumed by Deno, and what should be made available for the script. Currently it is assumed anything after the main script is to be consumed by the script, anything before the main script is to be consumed by Deno.

The only other solution is to introduce something like -- to make that demarkation, which just seems worse than the current solution.

ConsoleTVs

comment created time in 24 days

issue commentdenoland/deno

Feature Request: requestAnimationFrame

@yorkie no... Electron binds together Chromium and Node.js, so in theory someone could bind together Chromium and Deno, but that would not be this project.

Fenzland

comment created time in 25 days

push eventkitsonk/deno

Yoshiya Hinosawa

commit sha 9c22961b6a06a75dad68bad87328857a9f7a55dc

feat(website/benchmark): enable zoom of charts (#2668)

view details

Bartek Iwańczuk

commit sha 70de8dd51d465ea2016d6bb7c0728111f4493668

save headers for all intermediate redirects (#2677)

view details

Kevin (Kun) "Kassimo" Qian

commit sha e49d1e16ca2fca45e959c1add9b5a1d6866dbb90

feat: expose writeAll() and writeAllSync() (#2298) Symmetric with `readAll()` and `readAllSync()`. Also used in `xeval`. Also correct usage in `writeFile()`/`writeFileSync()`.

view details

Bert Belder

commit sha 1406961d2b32b6ff9d842e13d2add124b7e3119d

Add error handling for dynamic imports to libdeno (#2678)

view details

Nayeem Rahman

commit sha 589643d55768acf14c4a111b49881e7cd4b7bc7d

Fix anchor link destination (#2679)

view details

Maxim Mazurok

commit sha b7026816b6c45be0d68880568989698856b30b7f

Typo fix (#2592)

view details

Bartek Iwańczuk

commit sha 3ae808986d583ab4e151a7799acee4680c66bd78

cli: unify deno -h options (#2682)

view details

Bartek Iwańczuk

commit sha 89e6792203678a2ae4911e006fcf9b26f63c700d

cli: handle deno -v and deno --version (#2684)

view details

Bartek Iwańczuk

commit sha 729c4e9377c2112d51cefb6eb0c723cbaf2a1ff5

make importmap flag global (#2687)

view details

hashrock

commit sha 877e5ed7844a1754080ddff9c095ed941072775f

use animated-deno-logo in denolib (#2691)

view details

Bartek Iwańczuk

commit sha 187310a3e151303504a1dc5830334ae7ac1fef57

benchmarks: add bundle size (#2690)

view details

Bartek Iwańczuk

commit sha ff96e3dc637974c6f9853f3bf9565bfd63f22b17

benchmarks: make latency benchmark less noisy (#2689)

view details

Kitson Kelly

commit sha 5083f5fd908057cbc8649b79c13ab78a7f7ebf34

Remap stack traces of unthrown errors. (#2693)

view details

Bartek Iwańczuk

commit sha ac269beabe1b16294118e64e69bf487639086941

feat: add debug info to ModuleResolutionError (#2697)

view details

push time in 25 days

issue commentmicrosoft/TypeScript

All incompatibility with ECMAScript should be listed as open issues

@RyanCavanaugh would be more than glad to contribute to such a thing in the handbook. I know of a couple personally (like proper string iteration on downlevel emit #2585, and mixing of ES5/ES2015+ plus code causing issues in certain situations ref: #17088) and I guess not being able to extend built-ins in ES5 (which isn't really a TypeScript issue, more than TypeScript doesn't know it can't extend certain things in a down-emit).

falsandtru

comment created time in 25 days

Pull request review commentdenoland/deno

refactor: cleanup compiler pipeline

 pub fn source_code_version_hash(   gen_hash(vec![source_code, version.as_bytes(), config_hash]) } -fn load_config_file(-  config_path: Option<String>,-) -> (Option<PathBuf>, Option<Vec<u8>>) {-  // take the passed flag and resolve the file name relative to the cwd-  let config_file = match &config_path {-    Some(config_file_name) => {-      debug!("Compiler config file: {}", config_file_name);-      let cwd = std::env::current_dir().unwrap();-      Some(cwd.join(config_file_name))-    }-    _ => None,-  };--  // Convert the PathBuf to a canonicalized string.  This is needed by the-  // compiler to properly deal with the configuration.-  let config_path = match &config_file {-    Some(config_file) => Some(config_file.canonicalize().unwrap().to_owned()),-    _ => None,-  };--  // Load the contents of the configuration file-  let config = match &config_file {-    Some(config_file) => {-      debug!("Attempt to load config: {}", config_file.to_str().unwrap());-      match fs::read(&config_file) {-        Ok(config_data) => Some(config_data.to_owned()),-        _ => panic!(-          "Error retrieving compiler config file at \"{}\"",-          config_file.to_str().unwrap()-        ),-      }-    }-    _ => None,-  };--  (config_path, config)-}- pub struct TsCompiler {-  pub deno_dir: DenoDir,+  pub file_fetcher: SourceFileFetcher,   pub config: CompilerConfig,-  pub config_hash: Vec<u8>,   pub disk_cache: DiskCache,   /// Set of all URLs that have been compiled. This prevents double   /// compilation of module.   pub compiled: Mutex<HashSet<Url>>,   /// This setting is controlled by `--reload` flag. Unless the flag   /// is provided disk cache is used.   pub use_disk_cache: bool,+  /// This setting is controlled by `compilerOptions.checkJs`+  pub compile_js: bool, }  impl TsCompiler {   pub fn new(-    deno_dir: DenoDir,+    file_fetcher: SourceFileFetcher,+    disk_cache: DiskCache,     use_disk_cache: bool,     config_path: Option<String>,-  ) -> Self {-    let compiler_config = match load_config_file(config_path) {-      (Some(config_path), Some(config)) => Some((config_path, config.to_vec())),-      _ => None,-    };--    let config_bytes = match &compiler_config {-      Some((_, config)) => config.clone(),-      _ => b"".to_vec(),+  ) -> Result<Self, ErrBox> {+    let config = CompilerConfig::load(config_path)?;++    // If `checkJs` is set to true in `compilerOptions` then we're gonna be compiling+    // JavaScript files as well+    let config_json = config.json()?;+    let compile_js = match &config_json.get("compilerOptions") {

Just a health warning, tsconfig.json supports JSONC, which serde does not support. This means that it will not be able to parse certain valid tsconfig.json files. When you scaffold a tsconfig.json via the tsc it includes comments, and so I think it will be a pretty common pattern in the wild to use JSONC. So detecting checkJs may need to be done in another way, likely a regular expression of some sort. It also might make sense to have the test fixtures have a tsconfig.json that includes comments.

bartlomieju

comment created time in 25 days

issue commentmicrosoft/TypeScript

All incompatibility with ECMAScript should be listed as open issues

Closing the issue with a definitive label of "won't fix" is much better than keeping an issue open and allowing someone to think it will eventually be fixed. Then developers can avoid them.

Using an issue repository also as an authoritative guide to using a language also is not a good pattern. An issue repository is for managing issues, nothing more or less.

falsandtru

comment created time in a month

issue commentoakserver/oak

🐞 Can't run examples

It looks like you haven't reloaded your cache.

Master would be using std@0.12.0 and not std@0.9.0 as pointed out in the bug. If you had run the demos before, this would explain the behaviour. Try $ deno --reload --allow-read --allow-net index.ts.

BevanR

comment created time in a month

issue commentmicrosoft/TypeScript

Top Level Await

Allowing it through, with no downlevel emit would be perfect for my use case. Treating it like import.meta makes sense. It needs to be adopted somehow.

kitsonk

comment created time in a month

push eventkitsonk/deno

Kitson Kelly

commit sha 532e2c52905dafd8d0d9321311d2306d6e6adf58

Remap stack traces of unthrown errors.

view details

push time in a month

PR opened denoland/deno

Remap stack traces of unthrown errors.

This is a redone PR of a previous one that works with current Deno. In the previous PR I had hoped to move the cache of the parsed source maps into Deno cache, but I think it is just better to iterate on that eventually when deno_dir settles down.

Fixes #1717

+517 -3

0 comment

13 changed files

pr created time in a month

push eventkitsonk/deno

Kitson Kelly

commit sha e5f829c1f5c9ed65d83988128a1fffd55ce9c8ed

Remap stack traces of unthrown errors.

view details

push time in a month

push eventkitsonk/deno

Bartek Iwańczuk

commit sha 89e6792203678a2ae4911e006fcf9b26f63c700d

cli: handle deno -v and deno --version (#2684)

view details

Bartek Iwańczuk

commit sha 729c4e9377c2112d51cefb6eb0c723cbaf2a1ff5

make importmap flag global (#2687)

view details

hashrock

commit sha 877e5ed7844a1754080ddff9c095ed941072775f

use animated-deno-logo in denolib (#2691)

view details

Bartek Iwańczuk

commit sha 187310a3e151303504a1dc5830334ae7ac1fef57

benchmarks: add bundle size (#2690)

view details

Kitson Kelly

commit sha f573c4ac6292b864267d760b75f4aa85b93feff7

Remap stack traces of unthrown errors.

view details

push time in a month

create barnchkitsonk/deno

branch : remap-unthrown-2

created branch time in a month

issue commentmicrosoft/TypeScript

Suggestion: "safe navigation operator", i.e. x?.y

Sorry @jhpratt @MatthiasKunnen I forgot we don't all share the same context on GitHub. I've been bouncing around here for a long while and have spent time with Ryan and Daniel IRL and briefly participated in the recent event that gave rise to my misunderstood inside joke. Apologies.

This whole issue though shows an interesting archeology of the design principles of TypeScript. Ryan raised it at a time where TypeScript might have actually considered syntax that pre-dated serious consideration in ECMAScript. It was around that time though where TypeScript internally was learning some lessons of predicting ES2015 syntax that were having serious impacts on the language. The team decided to not consider inclusion until there was a TC39 Stage 3 proposal.

While @RyanCavanaugh can address it, and I know he has been close to what has happened with the proposal, I suspect it would have been unlikely what the team would have implemented back in 2014 would have been 100% compatible with the current Stage 3 proposal. So while it certainly is a celebration, also be thankful that we don't have 5 years of TypeScript code out that with a safe navigation operator that would not be entirely consistent with the behaviour in the proposal.

RyanCavanaugh

comment created time in a month

issue commentmicrosoft/TypeScript

Suggestion: "safe navigation operator", i.e. x?.y

I am going to @ @RyanCavanaugh because he is probably unsubscribed to this thread and I want to be rude! (and @DanielRosenwasser for good measure)

RyanCavanaugh

comment created time in a month

PR closed denoland/deno

Apply source maps to non thrown errors.

Fixes #1717

This PR fixes the issue where errors are caught or created but not thrown and then logged to the console. Currently, the stack trace would show emitted code locations and not the source location in the stack trace. This PR ops into Rust to remap the locations based on the source maps that are part of the module meta data.

This also exposes Deno.applySourceMap() which takes a location and returns the original location, so custom processing of errors and error stacks can be done.

I have an integration test, but wasn't going to finalise the unit tests until I got feedback about the exposure of the Deno.applySourceMap().

+402 -3

3 comments

11 changed files

kitsonk

pr closed time in a month

pull request commentdenoland/deno

Apply source maps to non thrown errors.

Do you want to pursue or close and revisit later?

I am going to port parts over to another branch and finish it up. It is what I will work on when I have the time. So let's close this one for now.

kitsonk

comment created time in a month

issue commentdenoland/deno

proposal: separate Caching + TypeScript from Deno core into std

The compiler is currently implemented as a web worker, though it isn't exposed or started via the main runtime isolate.

Service Workers are a specific type of web worker geared for proxying network requests. Not really designed for what the compiler does/needs to do.

oldrich-s

comment created time in a month

issue commentdenoland/deno

Public API for compilers

Service Workers aren't really suitable for a public compiler API. Service Workers are a specific class of Web Workers anyways. The existing compiler is implemented as a web worker, and a specific class of web worker would also be suitable IMO for the public compiler API, which is laid out above.

kitsonk

comment created time in a month

Pull request review commentdenoland/deno_std

WIP: JSDOM port

+import "./vendor/jsdom.js";++// TODO: Investigate how to reuse typings from:+// - https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jsdom/index.d.ts+// - https://github.com/microsoft/TypeScript/blob/master/lib/lib.dom.d.ts

There isn't really a way at the moment. It is covered by denoland/deno#1432.

MarkTiedemann

comment created time in a month

issue commentmicrosoft/TypeScript

Array.isArray refinement loses the array's type

So why are you being combative?

So feels like it is the other way around to me. 🤷‍♂

lll000111

comment created time in a month

push eventkitsonk/deno

Ryan Dahl

commit sha a00d087b39da7894276c2292335d2709a6cebd8c

Improve example on homepage (#2667)

view details

Bartek Iwańczuk

commit sha 34f212f257af3ccce4a1cb8e9b75b9cb5cb1c13b

fix: bring back --no-fetch flag (#2671)

view details

andy finch

commit sha c98d9bf7097575ec9832864f0e0d076a4763717c

removed unnecessary implementation from SourceFileFetcher (#2670)

view details

push time in a month

issue commentdenoland/deno

Handle output of TS compiler for JS and JSON files

Currently TS compiler doesn't perform any trasformation on .json files, ie. output of compiler is the same as input file.

That is right, the TypeScript compiler doesn't, but the Deno compiler used to, before the ESM. It would do exactly what is suggested in the link you sent:

For something like this:

{ "foo": "bar" }

You would get:

define("foo.json", [], function () {
  return JSON.parse(`{ "foo": "bar" }`);
});

The problem I just realised is that it isn't possible to generate a module that spreads the results of a string. Each export (key of the imported JSON) of the parsed JSON has to be available statically in ESM. The only real way to do it I think in ESM is how Ry did it. 😢 The other way is the compiler actually parses the JSON, enumerates over the keys and creates an export statement for each one.

Can I assume that unless checkJs is set to true we should discard compiler output for .js files and discard it always for .json files?

Yes, sounds right to me. And changes to the source .js should invalidate the cache when checkJs is true.

bartlomieju

comment created time in a month

PR closed oakserver/oak

Update to std v.0.11.0
+80 -246

2 comments

3 changed files

serverhiccups

pr closed time in a month

pull request commentoakserver/oak

Update to std v.0.11.0

Sorry, I bumbped everything to v0.12 now and tagged it as a release.

serverhiccups

comment created time in a month

created tagkitsonk/oak

tagv2.2.0

A middleware framework for Deno's net server

created time in a month

push eventkitsonk/oak

Kitson Kelly

commit sha a2a18a1e909942247392df804a0725e40a3f4ed1

Update to Deno 0.12

view details

push time in a month

created tagoakserver/oak

tagv2.2.0

A middleware framework for Deno's net server

created time in a month

push eventoakserver/oak

Kitson Kelly

commit sha a2a18a1e909942247392df804a0725e40a3f4ed1

Update to Deno 0.12

view details

push time in a month

push eventkitsonk/deno

Yoshiya Hinosawa

commit sha 9c454998646ef49f652bc919f53503ed07a1c55c

Support window.onload (#2643)

view details

Ryan Dahl

commit sha 4e248ecda9bb31478c6db7f5e76fa12b64b516a9

v0.12.0

view details

迷渡

commit sha 181cfc9fb5bd2cbb7cd0a994a845e1901d256770

Adjust console constructor (#2649) https://github.com/denoland/deno/pull/2073#discussion_r303401539

view details

Ryan Dahl

commit sha 481a82c983e40201589e105e28be4ce809e46a60

Edits to manual (#2646)

view details

Bartek Iwańczuk

commit sha 8214b686cea3f6ad57d7da49a44d33185fdeb098

Refactor DenoDir (#2636) * rename `ModuleMetaData` to `SourceFile` and remove TS specific functionality * add `TsCompiler` struct encapsulating processing of TypeScript files * move `SourceMapGetter` trait implementation to `//cli/compiler.rs` * add low-level `DiskCache` API for general purpose caches and use it in `DenoDir` and `TsCompiler` for filesystem access * don't use hash-like filenames for compiled modules, instead use metadata file for storing compilation hash * add `SourceFileCache` for in-process caching of loaded files for fast subsequent access * define `SourceFileFetcher` trait encapsulating loading of local and remote files and implement it for `DenoDir` * define `use_cache` and `no_fetch` flags on `DenoDir` instead of using in fetch methods

view details

迷渡

commit sha a0b8f13f18b24924d050e196baf6132b27a6011f

Rename powershell highlighting to shell (#2654)

view details

迷渡

commit sha ac98bd8a7ce13e6aaf35d13b8743281df24806d7

fix timer's params length (#2655)

view details

Ryan Dahl

commit sha bc12a3ba56b39ba8dd3f5afcccebca177361eab2

Reorder tools/format.py so slowest are last (#2661)

view details

Ryan Dahl

commit sha 55ca0f09cb50f8bc6b0590a9a88febc41f91e51b

REPL shouldn't panic when it gets SIGINT (#2662)

view details

Ryan Dahl

commit sha a37bc0088f9de76108fe0bd9243c794b413d73cf

Remove hacky normalize_path (#2660)

view details

andy finch

commit sha 056c14617565291cb00df9fec6f9779a3669089f

Fix expected dyn before AnyError trait (#2663)

view details

andy finch

commit sha 042484d45afe129f0c08d387870e4c6de019c34b

remove v8::Locker from deno_respond (#2664)

view details

andy finch

commit sha 621af21e6eab9b0f736d5b6e8acc48dbad4a68d2

only use Locker when calling into js (#2665)

view details

push time in a month

issue commentdenoland/deno

Handle output of TS compiler for JS and JSON files

I would strongly object removing resolveJsonModule from the compiler options. This removes the ability for the compiler to enforce strong typing of import files. Not caching the output would be acceptable, IMO. I would recommend that it gets stripped out in the compiler results someway, before the compiler response gets serialised, so we simply "trust" that everything that is returned from the compiler should be cached. One thing, after Ry's compiler rewrite to support ESM that I never did spend understanding is how is imported JSON injected into the runtime? Is it more efficient to just take the string and dump it into the isolate? When we were doing AMD, the compiler itself would generate a .js file that was an AMD module the deserialised the JSON in its factory. It would think it maybe worth considering allow the compiler to do that, so there is a clear seperation of concerns that the compiler takes all input assets being imported and outputs valid JSON. If it is truly more efficient to have that just dumped into the isolate some other way, I think the design needs to address the logical flow that an extensions/mime-type has a "compiler". The compiler may request n other resources to generate a compilation, and the generated compilation is cached. The main module gets injected in the isolate and pulls in what ever other JS files that are then requested, hopefully all of them coming from the cache, because it was generated by the compiler.

The checkJs has not been fully re-enabled. I believe I mentioned before somewhere that I was concerned about the future because it is legitimate that the compiler can take in an input of .js and output .js that is different. That is legitimate for our current compiler and legitimate for other userland compilers when we add the feature. The caching of modules should accomodate that the input is one file and the output is a .js file, allowing for the input to be of any type including .js.

bartlomieju

comment created time in a month

issue commentoakserver/oak

Unpin deno_std dependencies

It would be nice to have releases as pinned but maybe an unpinned tag as well 😬

I guess I could keep master unpinned and when when we cut a release, pin it. I have been tagging releases with updates.

maybe this could be automated? Something like renovate/greenkeeper but for deno pkgs

Not with the way the changes break at this stage. Sometimes it is just deno_std <-> Deno, sometimes it is something in deno_std <-> oak, sometimes it is Deno <-> oak. 🤷‍♂ Also sometimes Ry isn't tagging a deno_std release quickly after a Deno release, and so sometimes upgrading is hard. I think when things get more stable...

jeroenptrs

comment created time in a month

issue commentoakserver/oak

Unpin deno_std dependencies

I unpinned it before and there then are breaking changes in deno_std, so we need to pin, but I also need to keep updating with each release of Deno.

jeroenptrs

comment created time in a month

startedIntrinsicLabs/osgood

started time in a month

issue commentdenoland/deno

Node compatibility

@ry my suggestion is to scope what the expectations around require() are. It easily becomes a complicated thing, because of the rather complex module resolution logic (as I know you are aware), but it is resolution logic that lots of Node.js code relies upon. There are also the decorations on require() which a decent amount of code uses to hack around with.

Another couple thoughts about compatibility is:

  1. do you need to build it into Deno? Is there some preprocessing, potentially on the fly, that could be offloaded to an intelligent CDN? https://www.pika.dev/cdn takes ESM modules out of npm and bundles them for being loaded in the browser, resolving dependencies, etc. Something like that for Deno might be an easier path than building all the heavy lifting in the runtime engine.
  2. Is there some way the TypeScript compiler do the heavy lifting. While it wouldn't re-write module specifiers, it can convert JavaScript CommonJS modules to ES Modules. If we implemented whatever module resolution logic we wanted to support in Rust land and used the compiler to simply rewrite the modules to ES, we wouldn't have to implement require. I just can't remember what happens when you have a require() not at the top level. 🤔
ry

comment created time in a month

push eventkitsonk/deno

Long(Tony) Lian

commit sha 1d0d54247c0a5a69207f8e0b948d3b60287467eb

feat: fetch() now handles redirects (#2561)

view details

Bartek Iwańczuk

commit sha 3c81cca0374c96ff4759ec9305eb5529dd29a4d8

fix: prevent multiple downloads of modules (#2477)

view details

Bartek Iwańczuk

commit sha 70a9859adce478180a15d43877fe239a44379556

refactor: use Path/PathBuf in deno dir (#2559)

view details

Ryan Dahl

commit sha d1482c6b8abfdd8201f8d1845a5de75105f3cbc4

Upgrade deno_std (#2565)

view details

Ryan Dahl

commit sha 046cbef4f0f11e37d6ffb8b01c6362c8ce0b750d

simplify check_net test

view details

Bert Belder

commit sha 89216c7baaab8ade3daf9103572647addeb404f3

third_party: add rust crate 'termcolor'

view details

Ryan Dahl

commit sha 3a4d88475b40a17f2ce17b775a3f07c78be83d79

Port code from Cargo and use for progress A lot of its functionality is unused still, but the goal it to slowly migrate logging functionality to it. There is also a useful progress bar which can be ported over later - it depends on this module. https://github.com/rust-lang/cargo/blob/4c1fa54d10f58d69ac9ff55be68e1b1c25ecb816/src/cargo/util/progress.rs

view details

Ryan Dahl

commit sha c56df45355c8e68eabbfa62021e7ca7484115c0b

v0.10.0

view details

Evgeniy Karagodin

commit sha d089f9797830a2729cbd45cb4ea6312eb43a28de

Add homeDir to Deno namespace (#2578)

view details

Bartek Iwańczuk

commit sha 6906a2f75e428221f8b9bfa28b2c6821eb3ebe30

feat: deno completions command (#2577)

view details

Jimmy Cao

commit sha fb6d57a28172aeaaa5fdb31d5775e190bdfaa1c1

fix: run blocking function on a different task (#2570) This avoids freezing the current task if the fn blocks indefinitely

view details

Kitson Kelly

commit sha c50d4c01edad7fefbfcad0e956f25c4afbebed4e

Apply source maps to non thrown errors.

view details

Gurwinder Singh

commit sha d7d3e9f9dea7bf3f6e0c6e15e1bb3d2326f0fdf9

Fix multiple error messages for a missing file (#2587)

view details

迷渡

commit sha a5441003fe54dbdd93d243d2a5f3732447464e0c

rename shellsession to shell (#2583)

view details

andy finch

commit sha 83fe39701651058ae8c824621b7ef3849704fe07

update rust version for ci (#2599)

view details

matzkoh

commit sha 1b48d67fbba55d64372052879d26bf8e2143d9c7

docs(style_guide): fix typoFixes a small syntax error (#2567)

view details

Ryan Dahl

commit sha cde81c6a53bcb7e5e12a1f8d6003826544eff38e

manual: adjust windows build instructions (#2601)

view details

Bartek Iwańczuk

commit sha 38cf346d5c0f69dfb0919781fb61db7a6597ded1

feat: parse flags after script name (#2596)

view details

Bartek Iwańczuk

commit sha 5a4bebb77080d8a72a3faa594a388c6bce46e346

fix: test output for completions (#2597)

view details

Yoshiya Hinosawa

commit sha 1068b4848c4d6d9a444d2d2bca5f25d822c42ff5

ts_library_builder: update README (#2604)

view details

push time in a month

push eventkitsonk/deno

迷渡

commit sha 6a5177dc11936687e6da95c3c45e3e41a7856d79

event `isTrusted` is enumerable (#2543)

view details

Ryan Dahl

commit sha f2c50fae844b34cf6d8488ab1fbc599eb935a919

Fix silent failure of WebAssembly.instantiate() (#2548) By making WASM compilation synchronous. We'll have to do more work to make it properly async.

view details

Bartek Iwańczuk

commit sha 77a00aef4cef31e1e76549b3fcef25f389c0ab84

feat: upgrade installer and add docs (#2551)

view details

Matt Harrison

commit sha 20f41e719d2cb5add8e9168d00f239843fd56d31

Fix comment (#2555)

view details

andy finch

commit sha eb93dc58a11d9e9a295eff31f9c2c6a3a4c5170b

add encodeInto to TextEncoder (#2558)

view details

Bartek Iwańczuk

commit sha 642eaf97c67c6070935a2977014c743ba59deff8

feat: redirect process stdio to file (#2554)

view details

Yoshiya Hinosawa

commit sha 201ddd29a7908d457ed43b030476707d32848868

fmt_test: resolve old absolute path issue (#2562)

view details

Yoshiya Hinosawa

commit sha 988bcbb8842d12202f278808698a6b546718e764

fetch: make body async iterable (#2563)

view details

Bartek Iwańczuk

commit sha b9fbd552149c1fe61b662c9b1a1ed1b42e5487ae

feat: log permission access (#2518) Replaces -D/--log-debug flag with --log-level=debug --log-level=info displays permission access

view details

Gurwinder Singh

commit sha 6fa6828e5f0f7abac20ec342ee5ec57654a425d0

Minor tweaks (#2569) 1. Separate Snapshot and Script StartupData functions based on cfg "no-snapshot-init" 2. Replace deprecated Once::ONCE_INIT with Once::new (https://github.com/rust-lang/rust/pull/61757) 3. Elide lifetime 4. Fix typos

view details

JaePil Jung

commit sha d82089ca358b7fa4d5e2b7a357f651364643de7a

Update manual.md (#2571)

view details

Long(Tony) Lian

commit sha 1d0d54247c0a5a69207f8e0b948d3b60287467eb

feat: fetch() now handles redirects (#2561)

view details

Bartek Iwańczuk

commit sha 3c81cca0374c96ff4759ec9305eb5529dd29a4d8

fix: prevent multiple downloads of modules (#2477)

view details

Bartek Iwańczuk

commit sha 70a9859adce478180a15d43877fe239a44379556

refactor: use Path/PathBuf in deno dir (#2559)

view details

Ryan Dahl

commit sha d1482c6b8abfdd8201f8d1845a5de75105f3cbc4

Upgrade deno_std (#2565)

view details

Ryan Dahl

commit sha 046cbef4f0f11e37d6ffb8b01c6362c8ce0b750d

simplify check_net test

view details

Bert Belder

commit sha 89216c7baaab8ade3daf9103572647addeb404f3

third_party: add rust crate 'termcolor'

view details

Ryan Dahl

commit sha 3a4d88475b40a17f2ce17b775a3f07c78be83d79

Port code from Cargo and use for progress A lot of its functionality is unused still, but the goal it to slowly migrate logging functionality to it. There is also a useful progress bar which can be ported over later - it depends on this module. https://github.com/rust-lang/cargo/blob/4c1fa54d10f58d69ac9ff55be68e1b1c25ecb816/src/cargo/util/progress.rs

view details

Ryan Dahl

commit sha c56df45355c8e68eabbfa62021e7ca7484115c0b

v0.10.0

view details

Evgeniy Karagodin

commit sha d089f9797830a2729cbd45cb4ea6312eb43a28de

Add homeDir to Deno namespace (#2578)

view details

push time in a month

push eventkitsonk/nocuous

Kitson Kelly

commit sha feeca287a37ef12e1331ef3038e80905b02de3ba

Flesh out testing, finish off initial stats, update packaging.

view details

push time in a month

push eventkitsonk/nocuous

Kitson Kelly

commit sha bcf89390f1faf17a2dddb9248a919963e8df0449

Set up CI with Azure Pipelines [skip ci]

view details

push time in a month

issue commentdenoland/deno_std

suggestion: code style about async try catch

ESlint would yell if not used.

No it doesn't. The binding was not optional until recently, so it will just allow catch (e) because that was the only valid way to right it. ESLint is still debating the rule. The optional binding for catch statements is only part of ES2019 published in June (though there was a lot of adoption earlier than that, just not by eslint).

Dreamacro

comment created time in a month

issue commentdenoland/deno

Support d.ts files

The challenge is that many .d.ts files don't correlate 1:1 with JavaScript modules. In particular for large functional libraries, like things like lodash the absolutely don't correlate. Many many @types are "global" or "ambient" declarations, that describe a whole library. Some are written as UMD/modular types, but even then they may not correlate to TypeScript modules. So reading them and applying them to code is going to be very difficult, let alone what file it applies to.

On the other hand, you bring up an interesting potential, that if we settled on the conventions of resolving the @types for loading a JavaScript "package" off a CDN, then we could potentially try to remotely resolve the .d.ts files as remote code which we could cache. There might need to be some magic though. Hmmmm...

reggi

comment created time in a month

more