deno standard modules
Clone or download
Pull request Compare This branch is 30 commits behind denoland:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
colors
datetime
examples
flags
logging
mkdirp
net
path
testing
.editorconfig
LICENSE
README.md
azure-pipelines.yml
format.ts
test.ts

README.md

Deno Standard Modules

Build Status

  • colors

    Modules that generate ANSI color codes for the console.

  • flags

    Command line arguments parser.

  • logging

    Command line logging

  • mkdirp

    Make directory branches.

  • net

    A framework for creating HTTP/HTTPS servers inspired by GoLang.

  • path

    File path manipulation.

  • testing

    Testing

Style Guide

Use the term "module" instead of "library" or "package"

For clarity and consistency avoid the terms "library" and "package". Instead use "module" to refer to a single JS or TS file and also to refer to a directory of TS/JS code.

Use the filename "mod.ts" as the default entry point to a directory of code

index.ts comes with the wrong connotations - and main.ts should be reserved for executable programs. The filename mod.ts follows Rust’s convention, is shorter than index.ts, and doesn’t come with any preconceived notions about how it might work.

Within deno_std, do not depend on external code

deno_std is intended to be baseline functionality that all Deno programs can rely on. We want to guarantee to users that this code does not include potentially unreviewed third party code.

Within deno_std, minimize dependencies; do not make circular imports.

Although deno_std is a standalone codebase, we must still be careful to keep the internal dependencies simple and manageable. In particular, be careful to not to introduce circular imports.

For consistency, use underscores, not dashes in filenames.

Example: Instead of file-server.ts use file_server.ts.

Format code according using prettier.

More specifically, code should be wrapped at 80 columns and use 2-space indentation and use camel-case. Use //format.ts to invoke prettier.

Use JS Doc to document exported machinery

We strive for complete documentation. Every exported symbol ideally should have a documentation line.

If possible, use a single line for the JS Doc. Example:

/** foo does bar. */
export function foo() {
  // ...
}

See CONTRIBUTING.md for more details.

TODO Comments

TODO comments should be include an issue or the author's github username in parentheses. Example:

// TODO(ry) Add tests.
// TODO(#123) Support Windows.

Copyright headers

Most files in deno_std should have the following copyright header:

// Copyright 2018-2019 the Deno authors. All rights reserved. MIT license.

If the code originates elsewhere, ensure that the file has the proper copyright headers. We only allows MIT, BSD, and Apache licensed code in deno_std.

Top level functions should not use arrow syntax

Top level functions should use the function keyword. Arrow syntax should be limited to closures.

Bad

export const foo(): string => {
  return "bar";
}

Good

export function foo(): string {
  return "bar";
}

When referencing Deno online, use the #denoland tag.

The name "deno" unfortunately is not especially unique on the internet. In order to centralize the community, please tag github project, tweet, and other content with #denoland.


Copyright 2018-2019 the Deno authors. All rights reserved. MIT license.