This should be moved to https://github.com/denoland/deno_lint/

If we try to use this code, and we send raw text via postman decode will fail.

app.use(async (ctx) => {
  const result = ctx.request.body(); // content type automatically detected
  if (result.type === "json") {
    const value = await result.value; // an object of parsed JSON
  }


here is the error :

error: Uncaught SyntaxError: Unexpected token a in JSON at position 0
          JSON.parse(decoder.decode(await this.#valuePromise()));

    at JSON.parse (<anonymous>)
    at value (body.ts:202:16)

we need internal handling to solve this issue.

The only time the result.type would be set to JSON is when the Content-Type is set to application/json. If you set that content type and then send a body that is invalid JSON, the behaviour you are seeing is to be expected (that an error throws).

If there is a risk that someone might try to send invalid JSON in the payload, you should write the code to handle that properly, in a way that is meaningful to your application. For example:

app.use(async (ctx) => {
  const result = ctx.request.body(); // content type automatically detected
  if (result.type === "json") {
    try {
      const value = await result.value;
    } catch (e) {
      if (e instanceof SyntaxError) {
        ctx.throw(Status.BadRequest, e.message);
      } else {
        ctx.throw(Status.InternalServerError);
      }
    }
  }
});

I see that Oak is very much maintained and up-to-date, but on casual inspection, the latest version was released in May. With Deno's rapid development this is very discouraging for potential users. It is very misleading, can it be corrected?

Also, I can't find a changelog, is there one? Cheers.

That is a behaviour of "releases" in GitHub and it cannot be controlled (like a lot of things on GitHub). Please refer to the tags to determine the latest release. I may "release" every tag in the future, but I am not sure.

There is no change log at this point. Something I will consider in the future.

Basically what you are asking for is hot module reloading... That is problematic in a lot of ways. ES Modules and their exports are immutable by design. As stated in #5548 we should find better ways to do this to support things like development. There is discussion in #6694 about this as well.

Instead of asking for a specific feature, what use case are you trying to solve?

It solves enough of this problem to close the issue, certainly.

We currently committed code to master for std to be compatible with the version of the cli in master, and that flushed out a whole set of people complaining about the breaking changes and code not running. People are either ignoring the warning message, not understanding what it means, or depending on code that depends on master. All which lead to 😠 😭 😖.

Maybe we should introduce a release branch for the purposes of std which is created at the same time as the cli release, and point https://deno.land/std/ at that branch by default instead of master. We can then eliminate the warning code in the cli as well. I believe it is reasonable to expect https://deno.land/std/ to be compatible with the current release of the cli, even though people should still depend on specific versions as a matter of best practice.

Link is in the repo description: https://oakserver.github.io/oak/

GitHub can now be published of any branch.

Why do we even have to store dynamically imported modules in cache?

Because that is very similar to the way browsers work. Clearly dynamic implies something to you that it doesn't actually mean to imply, it means "allow me to conditionally run this code in the current execution context", but all the rules to how modules are fetched, compiled and imported apply whether it be static or dynamic.

Ultimately this is a duplicate of #5548 and #6694

Yeah, I need to rework it. Certainly possible to do as a seperate package as well.

Just for context, there is a small amount of dependencies that not type checking would not catch currently, that would be caught under type checking.

For example:

const a = "./a.ts";
const a_mod = await import(a);

Would be caught under type checking, as the TypeScript compiler realises that value being passed to the dynamic import is statically determinable at call point, and would then make "./a.ts" a dependency of the module.

@bartlomieju looks like the type stripping isn't stripping types. 😭

Code:

import { Application } from "https://deno.land/x/oak/mod.ts";

const body = "Hello World"
const app = new Application();

app.use((ctx) => {
  ctx.response.body = `<!DOCTYPE html>
  <html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
  </head>
  <body>
    ${body}
  </body>
  </html>`;
});

await app.listen({ port: 8000 });

deno --version

Output:

deno 1.2.1
v8 8.5.216
typescript 3.9.2

Error:

error: TS2345 [ERROR]: Argument of type 'string | URL' is not assignable to parameter of type 'string'.
  Type 'URL' is not assignable to type 'string'.
  return new URL(url).pathname
                 ~~~
    at https://deno.land/[email protected]/path/win32.ts:917:18

TS2345 [ERROR]: Argument of type 'string | URL' is not assignable to parameter of type 'string'.
  Type 'URL' is not assignable to type 'string'.
  return new URL(url).pathname;
                 ~~~
    at https://deno.land/[email protected]/path/posix.ts:438:18

Note: It is working file with [email protected]

You need to reload your cache deno run --reload whatever.ts.

Please don't use an unpinned version of oak, as it will lead to this very specific issue and is clearly mentioned in the README:

Warning The examples in this README pull from main, which may not make sense to do when you are looking to actually deploy a workload. You would want to "pin" to a particular version which is compatible with the version of Deno you are using and has a fixed set of APIs you would expect. https://deno.land/x/ supports using git tags in the URL to direct you at a particular version. So to use version 3.0.0 of oak, you would want to import https://deno.land/x/[email protected]/mod.ts.

Currently you should use https://deno.land/x/[email protected]/mod.ts which is the latest release.

Blocked by #106, we are not going to introduce an external library to instrument the code, we are going to get it directly from V8 and built it into the test harness. There are other solutions for the Rust code, we just need to integrate them into the CI process.

I don't think the lack of code coverage is a big factor in people making a decision about contributing or not, personally.

If you supply a lib attribute in your compiler options, it will always override the defaults, and you need to include deno.ns. What happens when you omit a lib attribute in your tsconfig.json?

It should read "some bundles can also be loaded in the web browser". There are all sorts of things that can make bundles incompatible with browsers.

Top level await is already in V8 and being implemented in Chromium, so it will eventually end up in Chrome and Edge.

We have a close relationship with the TypeScript core team. The problem here is that the main maintainer doesn't have the time to maintain it and so @ry is trying to pick up the challenge as mentioned above. I would personally take it up, but I have limited time to dedicate to Deno at the moment and I've been buried in another thing. We will get it sorted out for sure, but it will take a bit of time.

In my opinion, that feels like an highly opinionated "framework" that should start life outside std and only come into std if it become a de facto.

In my opinion, that feels like an highly opinionated "framework" that should start life outside std and only come into std if it become a de facto.

@pomke the tokens are tied to users, not repos... it would be a limitation that the same user has to have read access to all the repos. That is a limitation that seems reasonable.

In fact we will be breaking those APIs: #4752

We need to get it implemented on the command line and with environment variables first, and iterate from there. We don't need to solve every problem at the start.

I don't see how this issue is unique/different from #6706 you opened, which is far more specific about what capabilities you would like to see... For the sake of everyone's sanity, could we try to keep the discussion in one issue, up until there is something actionable that warrants creating multiple issues?

This would have no effect without explicitly upgrading std and there's no transitive effect from an intermediary dependency updating its version of std.

That is the residual issue. When we merged with master, we had a load of people up in arms, because they were on 1.1.3 and their dependency was using std from master, which then was breaking. The fix of not serving the main branch, but the latest release with a "bare" specifier wouldn't fix it either, because as soon as we release that version of standard, we would break a lot of libraries that exist out there that are using the latest release of std that would need to be updated. I know it would break the main branch of oak, and the fact that this required changes in 20+ files indicates how pervasive this API. Mostly because there really isn't anything in the browser standards that comes close to providing the functionality, so we have no choice.

I am all for breaking things, but as pointed out, this is 6 of one, half dozen of another. For every argument on this API there is an equal counter argument against. In my mind, the APIs in std are JavaScript convention first, Go Lang second, then other prior art. There is a strong convention with Node.js in this space, and Go Lang is semi-aligned to that. Sadly, Rust is the outlier here.

In my mind, a breaking change that doesn't have a strong compelling argument coupled with wide 3rd party adoption, is a challenge.

While dirname() is non sensical to some, parent() is non sensical to others.

Go Lang, which is the "default" for std APIs:

• basename() -> base()
• dirname() -> dir()
• extname() -> ext()
• sep -> separator

Also, this wouldn't be a minor breaking change, it would have significant impacts, and we originally thought correcting URL | string was a good idea and look at the impact that had. If this was a year ago, I would have thought it would be a good conversation to debate, but sadly, I think the cowpath is already paved.

Duplicate of #6706 and #3456 which was closed by #6520.

Possibly... We were talking about introducing a top level option of --isolated in addition to the existing --no-check which would set the config to "isolateModules": true without needing to use a --config tsconfig.json. We could use the code paths then to just do the type checking with no emit and then use the swc type stripping, even before we could do the AST transform. That would be a stepping stone to making that the default in a future version.

@bartlomieju after the compiler refactor, my opinion is that we need to investigate the swc AST -> TypeScript AST and feed the compiler pre-parsed AST (this in theory would also open the door to just using tsc for type checking as well, but as we discussed, we can't do that without a significant breaking change, because Deno would only work effectively with "isolatedModules": true).

Ref denoland/deno#6723 there are changes afoot so that documentation doesn't have to be updated on every release.

Everyone had to re-sign the CLA, as the terms were changed.

Nightly clippy flags these up as errors, but there appears to issue with adopting this style prematurely.

Duplicate of #1863

Can you git mv the various typescript files so the diff was easier to look at?

If I did that right now, it would break CLI, so I have simply hacked around it for now.

deno lint was added in 59782a5917c58187b27c490d0a3cb69b1a3aa7ac.

The following code triggers the rule no-this-alias inappropriately:

const { value } = this;

The rule should be catching only things like this:

const self = this;

Super yucky! It really shouldn't be doing that.

The context is the same, trust me.

Why you don't think it is the same is that .cookies.get() only looks at cookie values in the request and not anything in the response. Because of the support for verified keys, I am not too keen on changing the behaviour, it would make it appear that the cookie is actually part of the request, when it isn't.

I would simply have the middleware move the session state in and out of the context.state... So something like this:

let sessionId = context.cookies.get(SESSION_ID);
let state;
if (!sessionId) {
  sessionId = // new guid
  context.cookies.set(SESSION_ID, sessionId);
  // init state
}
context.state.session = // get state 
await next();
// whatever other cleanup, persistence, whatever
delete context.state.session;

That way, consumers of your middleware don't have to even think about it, they will simply use:

context.state.session.whatever

npm install -g with a postinstall hook ~can add~ has added your computer to a crypto-mining farm (in the past)

We already use swc in Deno. Again this is still a long term goal, as there are a load of other things we need to do (including ones related to bundling, see: #4549) before this became a priority, some of which would block this (source maps for example).

I agree that compiler refactor is important, I don't suggest trying to hook SWC up to type checking process in this PR. Are you ok with landing change just for --no-check?

Yeah, I hadn't actually looked at the changes... straight forwards and should be easy to integrate. 👍

Thinking more, we might want to help people make the transition. I know we have avoided it, but if we surfaced --isolated as an option for run and check, then people would be able to easily run their code in type check and get back errors that are more meaningful to what they need to fix in order to support just type stripping. It would make the introduction of the breaking change easier.

This would be a long term goal.

We couldn't use uglify as it doesn't work with modern JavaScript, uglify-es is no longer maintained, terser is the successor to uglify. Even then we wouldn't use it. We would look to swc though its minification likely needs improvement.

Also, Hermes is significantly slower than V8 as well (34 times slower based on that benchmark). I am afraid there are a lot better paths to #986 than using Hermes.

Couple thoughts... I know we are eager to do this, but I think the refactor of the compiler is important (#6894). This should be even easier to implement when that is redone.

Second, we can't use it for the type checking without breaking a lot of code in the wild, especially code that doesn't use export type and import type plus const enum and potentially other code. (You want to run it with "isolatedModules": true so that the type checking is as close to just type stripping as possible). Honestly we wouldn't be able to do that until 2.0 IMO.

This is a major refactor of the TypeScript compilation infrastructure. Raising for early visibility, but it is still very much a work in progress. It totally rewrites how the compilations are handled to abstract out the logic, which should make it easier to move parts and pieces in the future, at the same time leveraging more Rust infrastructure and signficantly "dumbing" down the interface to the TypeScript compiler.

Currently it is a seperate crate as that has been easier for me to work on it without having to deal with merge conflicts and other changes.

Currently I have the following working:

• Ability to create snapshots with custom libs (like deno.ns).
• Ability to compile a set of sources and specify any custom libs to type check against.
• Ability to transpile an arbitrary set of sources.

Things that I need to do:

• Introduce bundling, which the bundle creation will be done in Rust, using the TypeScript compiler just for type checking and transpilation.
• Finish off the display of the diagnostics.
• Look at moving the dependency graph logic in.
• Integrate into the CLI.

When finished this will:

Fixes #5606 Fixes #5607 Fixes #6686

This should be closed.

Babel and typescript-eslint set exportKind to "type" instead of "value": https://astexplorer.net/#/gist/408ad6e07e866fd7743725e9073bdf5b/74e0f25919bf3f997a3d83dee2a3635fc701156a. TypeScript transpileOnly() will always strip export type and import type statements. The main reason the syntax was introduced was to make type stripping possible (as export ... from ... cannot be statically determined to be a type or not).

Erroring I suspect would be a challenge, since it is valid TypeScript and we wouldn't want to @ts-ignore it.

Normally you don't want to grab a reference to the context, but instead have a middleware that does pre and post processing before other middleware that needs that occurs. It could set something in the .state per request, like:

app.use(async (context, next) => {
  context.state.session = "whatever";
  await next();
  delete context.state.session;
});

If you are obsessed about hiding it, use a symbol that only you have reference to as the key.

But if you are really obsessed about hiding it:

const myPrivateData = new WeakMap();
myPrivateData.set(context, "something");

The context object is the same object through the handling of the request.

Because of these types of issues: https://github.com/deligenius/view-engine/issues/13

Thanks, but needed to upgrade the Deno version for CI as well as fix the formatting error.

Fixed in f3623d95f17a12ad0dbf7c5780736b515edc29fd

This will not update the Deno CLI to TypeScript 3.9.7. This simply updates the version of TypeScript typescript-eslint uses.

Duplicate of #6338

Regarding the type stripping: #6864 is the tracking issue.

context.state? Which can be strongly typed using generics?

@jimmywarting unless it gets implemented in the standard, it won't get implemented in Deno.

As stated this is already implemented, and we have plans for improving it.

Also see #5432 which is effectively the master issue for all this work.

Ah, I mis-read what you said. I thought you were suggesting the behaviour of Deno was to silently drop the cookie header, but it is browsers.

The problem is fetch() will always behave differently in a server context and a client context. You have all the situations with same origin and cross origin which just don't make sense in a server context. I am still just for documenting it. As you state, Node's implementation just passes forbidden as well.

It is that or we implement some sort of cookie jar per origin that manages the cookies itself, and set the cookies on the document if you "really" want browser compatibility, but that just doesn't seem logical to me.

I see that two, just because someone posts something on Stack Overflow as an answer doesn't make it true. I specifically tested against IE11 and had no issue with content-type. I suggest you try it yourself as well.

In my refactor of the compiler branch, I have all of the parsing and processing of the tsconfig, including the ignoring the options we ignore in Rust now.

Duplicate of #6338

The behaviour is to silently drop them, at least in Chrome. I just did:

await fetch("http://localhost:8000", { headers: new Headers([["cookie", "foo=bar"]]) });

And it simply stripped the cookie header. The reason why they are forbidden is because the user agent controls them, and can't be overridden by user land. We should simply document the behaviour in my opinion, since there is no browser error when passed.

@chovy that additional error you have is that the code is not --no-check safe. ./levels.ts is re-exporting a type that does not have a runtime emit. So instead of export { SomeInterface } from "whatever.ts" you should use export type { SomeInterface } from "whatever.ts".

deno info --no-check main.ts should give you a full dependency tree.

Well, and a lot of folks who want to support Deno and Node.js with a single distributable of JavaScript plus TypeScript types. It would mean a lot of folks would not be able to consume that JavaScript in a type safe way as the authors intended.

I just tried with IE11 and had no issues with an all lowercase content type.

Correct. That is the behaviour of Headers() in the browser, of which the Deno implementation is used underneath: https://fetch.spec.whatwg.org/#terminology-headers.

Is this causing some sort of problem? It shouldn't.

There are a lot of things that "work" at runtime that aren't valid when you type check. If you don't want to type check it, use --no-check or // @ts-nocheck in the file.

It was valid at the time the bug was reported. Deno has changed since then.

As you pointed out Deno does support it. You just have to know the module name. Let alone augmenting existing TypeScript is "dangerous" in my opinion, like augmenting built in globals.

Your best approach is to import whatever you want, augment it, and re-export it, and any code the needs the argumentation would depend on that re-export.

No. There are big reactors in the internals at the moment which make this something that would need to come afterwards.

You should replace deps.ts with a file that you have on your local machine. Likely what you run with deno run ....

Deno.transpileOnly does not resolve modules at all. You have to supply it sources. An import map makes no sense in that context.

@reselbob your problem is the same as the others. You are using Deno 1.2.0, but some dependency of yours is pulling in std prior to 0.61.0 (the log states it is 0.57.0). You need to identify the offending dependency and update it.

Everything is just an explicit URL with no "magic" resolution. This proposal would require magical resolution and coupling to things like how code is structured in GitHub. That is not something that Deno wants to do.

For the Deno namespace, if the Built-in modules proposal for ECMAScript/JavaScript ever got close to being adopted, Deno would consider using that syntax to make the Deno namespace a built-in module.

So, why wouldn't it be an issue for the plugin?

the first 5 lines at least in VSCode

Using what plugin? Why would this be an issue for the Deno CLI? Not entirely sure what problem this is causing either.