OSSForks/node
1
0
Fork 0
mirror of https://github.com/zebrajr/node.git synced 2026-01-15 12:15:26 +00:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity
25,384 Commits 30 Branches 683 Tags
b7bbd871afb7e0bc02b92ebdbd785371439e5295
Go to file
Clone
Open with VS Code Open with VSCodium Open with Intellij IDEA
Download ZIP Download TAR.GZ Download BUNDLE
Benjamin Coe b7bbd871af deps: v8, cherry-pick 9365d09, aac2f8c, 47d34a3 
Original commit message 9365d09:

        [coverage] Rework continuation counter handling

        This changes a few bits about how continuation counters are handled.

        It introduces a new mechanism that allows removal of a continuation
        range after it has been created. If coverage is enabled, we run a first
        post-processing pass on the AST immediately after parsing, which
        removes problematic continuation ranges in two situations:

        1. nested continuation counters - only the outermost stays alive.
        2. trailing continuation counters within a block-like structure are
           removed if the containing structure itself has a continuation.

        R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org

        Bug: v8:8381, v8:8539
        Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
        Reviewed-on: https://chromium-review.googlesource.com/c/1339119
        Reviewed-by: Yang Guo <yangguo@chromium.org>
        Reviewed-by: Leszek Swirski <leszeks@chromium.org>
        Reviewed-by: Georg Neis <neis@chromium.org>
        Commit-Queue: Jakob Gruber <jgruber@chromium.org>
        Cr-Commit-Position: refs/heads/master@{#58443}

    Refs: v8/v8@9365d09

    Original commit message aac2f8c:

        [coverage] Filter out singleton ranges that alias full ranges

        Block coverage is based on a system of ranges that can either have
        both a start and end position, or only a start position (so-called
        singleton ranges). When formatting coverage information, singletons
        are expanded until the end of the immediate full parent range. E.g.
        in:

        {0, 10}  // Full range.
        {5, -1}  // Singleton range.

        the singleton range is expanded to {5, 10}.

        Singletons are produced mostly for continuation counters that track
        whether we execute past a specific language construct.

        Unfortunately, continuation counters can turn up in spots that confuse
        our post-processing. For example:

        if (true) { ... block1 ... } else { ... block2 ... }

        If block1 produces a continuation counter, it could end up with the
        same start position as the else-branch counter. Since we merge
        identical blocks, the else-branch could incorrectly end up with an
        execution count of one.

        We need to avoid merging such cases. A full range should always take
        precedence over a singleton range; a singleton range should never
        expand to completely fill a full range. An additional post-processing
        pass ensures this.

        Bug: v8:8237
        Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
        Reviewed-on: https://chromium-review.googlesource.com/c/1273095
        Reviewed-by: Georg Neis <neis@chromium.org>
        Reviewed-by: Yang Guo <yangguo@chromium.org>
        Commit-Queue: Jakob Gruber <jgruber@chromium.org>
        Cr-Commit-Position: refs/heads/master@{#56531}

    Refs: v8/v8@aac2f8c

    deps: V8: backport 47d34a3

    Original commit message:

        Revert "[coverage] change block range to avoid ambiguity."

        This reverts commit 471fef0469d04d7c487f3a08e81f3d77566a2f50.

        Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.

        Original change's description:
        > [coverage] change block range to avoid ambiguity.
        >
        > By moving the block range end to left of closing bracket,
        > we can avoid ambiguity where an open-ended singleton range
        > could be both interpreted as inside the parent range, or
        > next to it.
        >
        > R=<U+200B>verwaest@chromium.org
        >
        > Bug: v8:8237
        > Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
        > Reviewed-on: https://chromium-review.googlesource.com/1254127
        > Reviewed-by: Georg Neis <neis@chromium.org>
        > Commit-Queue: Yang Guo <yangguo@chromium.org>
        > Cr-Commit-Position: refs/heads/master@{#56347}

        TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org

        # Not skipping CQ checks because original CL landed > 1 day ago.

        Bug: v8:8237
        Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
        Reviewed-on: https://chromium-review.googlesource.com/c/1273096
        Reviewed-by: Jakob Gruber <jgruber@chromium.org>
        Reviewed-by: Toon Verwaest <verwaest@chromium.org>
        Reviewed-by: Yang Guo <yangguo@chromium.org>
        Commit-Queue: Jakob Gruber <jgruber@chromium.org>
        Cr-Commit-Position: refs/heads/master@{#56513}

    Refs: 47d34a317e

PR-URL: https://github.com/nodejs/node/pull/25429
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
2019-01-16 17:35:52 -08:00
.github
doc: add multiple issue templates for GitHub
2018-08-12 10:18:40 -07:00
benchmark
os: improve networkInterfaces() performance
2019-01-14 07:42:27 +01:00
deps
deps: v8, cherry-pick 9365d09, aac2f8c, 47d34a3
2019-01-16 17:35:52 -08:00
doc
doc: revert incorrect change on readable._read
2019-01-15 09:44:45 +05:30
lib
src: pass cli options to bootstrap/loaders.js lexically
2019-01-16 21:54:23 +08:00
src
src: call Environment::Exit() for fatal exceptions
2019-01-16 22:58:16 +08:00
test
test: refactor pummel/test-net-pingpong
2019-01-16 06:49:22 -08:00
tools
tools: lint for use of internalBinding()
2019-01-11 16:17:33 -05:00
.clang-format
tools: add make format-cpp to run clang-format on C++ diffs
2018-08-03 19:40:23 +08:00
.editorconfig
tools: unify .editorconfig rules for 2-space
2018-10-01 18:43:55 +02:00
.eslintignore
test: run eslint on test file and fix errors
2018-12-15 06:55:02 -08:00
.eslintrc.js
tools: enable no-useless-catch lint rule
2018-12-29 13:36:57 -05:00
.gitattributes
src: limit .gitattributes eol to vcbuild.bat
2015-01-13 22:33:52 +11:00
.gitignore
build: add .DS_store to .gitgnore
2018-10-15 12:08:04 +02:00
.mailmap
doc: update AUTHORS list
2018-09-14 18:58:47 +02:00
.nycrc
test: fix tests that fail under coverage
2018-05-22 12:45:54 +04:00
.travis.yml
build: remove sudo:false from .travis.yml
2018-11-20 10:26:49 -08:00
android-configure
build: don't create directory for NDK toolchain
2017-03-21 22:52:55 -07:00
AUTHORS
doc: update AUTHORS list
2018-09-14 18:58:47 +02:00
BSDmakefile
node: rename from io.js to node
2015-08-23 17:59:43 -04:00
BUILDING.md
doc: add help on fixing IPv6 test failures
2018-11-16 17:23:14 -05:00
CHANGELOG.md
2018-12-26, Version 11.6.0 (Current)
2018-12-26 11:24:51 -05:00
CODE_OF_CONDUCT.md
doc: simplify CODE_OF_CONDUCT.md
2018-11-01 23:28:41 -07:00
COLLABORATOR_GUIDE.md
doc: revise "Breaking Changes to Internal Elements"
2018-12-26 08:13:40 -08:00
common.gypi
deps: v8, cherry-pick 9365d09, aac2f8c, 47d34a3
2019-01-16 17:35:52 -08:00
configure
build: move meta-shebang back to configure
2018-09-07 10:17:52 -04:00
configure.py
build: add check for empty openssl-fips flag
2019-01-11 05:39:00 +01:00
CONTRIBUTING.md
doc: streamline CONTRIBUTING.md
2018-11-05 05:59:49 +01:00
CPP_STYLE_GUIDE.md
doc: fix heading in cpp style guide
2019-01-08 00:54:36 +01:00
GOVERNANCE.md
doc: wrap GOVERNANCE.md at 80 characters
2018-11-07 09:27:32 -08:00
LICENSE
deps,tools: update license-builder.sh and LICENSE
2019-01-05 21:36:45 +01:00
Makefile
build,test: fail coverage target if tests fail
2019-01-15 07:58:39 +01:00
node.gyp
process: refactor coverage setup during bootstrap
2019-01-16 13:49:36 +08:00
node.gypi
zlib: add brotli support
2019-01-05 21:36:46 +01:00
README.md
doc: make README formatting more consistent
2018-12-15 21:28:30 +01:00
SECURITY.md
doc: add SECURITY.md to readme.md
2018-11-04 00:08:18 -07:00
vcbuild.bat
win, build: fix building addons on Windows
2018-12-31 01:31:51 +01:00

README.md

Node.js

Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. For more information on using Node.js, see the Node.js Website.

The Node.js project uses an open governance model. The Node.js Foundation provides support for the project.

This project is bound by a Code of Conduct.

Table of Contents

Support

Node.js contributors have limited availability to address general support questions. Please make sure you are using a currently-supported version of Node.js.

When looking for support, please first search for your question in these venues:

If you didn't find an answer in the resources above, try these unofficial resources:

GitHub issues are for tracking enhancements and bugs, not general support.

The open source license grants you the freedom to use Node.js. It does not guarantee commitments of other people's time. Please be respectful and manage your expectations.

Release Types

  • Current: Under active development. Code for the Current release is in the branch for its major version number (for example, v10.x). Node.js releases a new major version every 6 months, allowing for breaking changes. This happens in April and October every year. Releases appearing each October have a support life of 8 months. Releases appearing each April convert to LTS (see below) each October.
  • LTS: Releases that receive Long-term Support, with a focus on stability and security. Every even-numbered major version will become an LTS release. LTS releases receive 18 months of Active LTS support and a further 12 months of Maintenance. LTS release lines have alphabetically-ordered codenames, beginning with v4 Argon. There are no breaking changes or feature additions, except in some special circumstances.
  • Nightly: Code from the Current branch built every 24-hours when there are changes. Use with caution.

Current and LTS releases follow Semantic Versioning. A member of the Release Team signs each Current and LTS release. For more information, see the Release README.

Download

Binaries, installers, and source tarballs are available at https://nodejs.org/en/download/.

Current and LTS Releases

https://nodejs.org/download/release/

The latest directory is an alias for the latest Current release. The latest-codename directory is an alias for the latest release from an LTS line. For example, the latest-carbon directory contains the latest Carbon (Node.js 8) release.

Nightly Releases

https://nodejs.org/download/nightly/

Each directory name and filename contains a date (in UTC time) and the commit SHA at the HEAD of the release.

API Documentation

Documentation for the latest Current release is at https://nodejs.org/api/. Version-specific documentation is available in each release directory in the docs subdirectory. Version-specific documentation is also at https://nodejs.org/download/docs/.

Verifying Binaries

Download directories contain a SHASUMS256.txt file with SHA checksums for the files.

To download SHASUMS256.txt using curl:

$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt

To check that a downloaded file matches the checksum, run it through sha256sum with a command such as:

$ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -

For Current and LTS, the GPG detached signature of SHASUMS256.txt is in SHASUMS256.txt.sig. You can use it with gpg to verify the integrity of SHASUM256.txt. You will first need to import the GPG keys of individuals authorized to create releases. To import the keys:

$ gpg --keyserver pool.sks-keyservers.net --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D

See the bottom of this README for a full script to import active release keys.

Next, download the SHASUMS256.txt.sig for the release:

$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt.sig

Then use gpg --verify SHASUMS256.txt.sig SHASUMS256.txt to verify the file's signature.

Building Node.js

See BUILDING.md for instructions on how to build Node.js from source and a list of supported platforms.

Security

For information on reporting security vulnerabilities in Node.js, see SECURITY.md.

Current Project Team Members

For information about the governance of the Node.js project, see GOVERNANCE.md.

TSC (Technical Steering Committee)

TSC Emeriti

Collaborators

Collaborator Emeriti

Collaborators follow the COLLABORATOR_GUIDE.md in maintaining the Node.js project.

Release Keys

GPG keys used to sign Node.js releases:

To import the full set of trusted release keys:

gpg --keyserver pool.sks-keyservers.net --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
gpg --keyserver pool.sks-keyservers.net --recv-keys B9E2F5981AA6E0CD28160D9FF13993A75599653C
gpg --keyserver pool.sks-keyservers.net --recv-keys 94AE36675C464D64BAFA68DD7434390BDBE9B9C5
gpg --keyserver pool.sks-keyservers.net --recv-keys B9AE9905FFD7803F25714661B63B535A4C206CA9
gpg --keyserver pool.sks-keyservers.net --recv-keys 77984A986EBC2AA786BC0F66B01FBB92821C587A
gpg --keyserver pool.sks-keyservers.net --recv-keys 71DCFD284A79C3B38668286BC97EC7A07EDE3FC1
gpg --keyserver pool.sks-keyservers.net --recv-keys FD3A5288F042B6850C66B31F09FE44734EB7990E
gpg --keyserver pool.sks-keyservers.net --recv-keys 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600
gpg --keyserver pool.sks-keyservers.net --recv-keys C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8
gpg --keyserver pool.sks-keyservers.net --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D
gpg --keyserver pool.sks-keyservers.net --recv-keys A48C2BEE680E841632CD4E44F07496B3EB3C1762

See the section above on Verifying Binaries for how to use these keys to verify a downloaded file.

Other keys used to sign some previous releases:

Contributing to Node.js

Reference in New Issue View Git Blame Copy Permalink
Description
Node.js JavaScript runtime ✨🐢🚀✨ nodejs.org
Readme Multiple Licenses 1.4 GiB
Languages
JavaScript 62.4%
C++ 23.1%
Python 10.1%
C 2.7%
HTML 0.6%
Other 0.9%