Skip to content

Commit

Permalink
doc: start unorded lists at start of line
Browse files Browse the repository at this point in the history
Address Markdownlint MD006 rule.
Can flag when list items aren't indented far enough.

PR-URL: #29390
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
  • Loading branch information
nschonni authored and Trott committed Sep 4, 2019
1 parent 3c84556 commit 27a57d3
Show file tree
Hide file tree
Showing 13 changed files with 718 additions and 715 deletions.
56 changes: 28 additions & 28 deletions doc/api/addons.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,34 +17,34 @@ for more information on N-API.
When not using N-API, implementing Addons is complicated,
involving knowledge of several components and APIs:

- V8: the C++ library Node.js currently uses to provide the
JavaScript implementation. V8 provides the mechanisms for creating objects,
calling functions, etc. V8's API is documented mostly in the
`v8.h` header file (`deps/v8/include/v8.h` in the Node.js source
tree), which is also available [online][v8-docs].

- [libuv][]: The C library that implements the Node.js event loop, its worker
threads and all of the asynchronous behaviors of the platform. It also
serves as a cross-platform abstraction library, giving easy, POSIX-like
access across all major operating systems to many common system tasks, such
as interacting with the filesystem, sockets, timers, and system events. libuv
also provides a pthreads-like threading abstraction that may be used to
power more sophisticated asynchronous Addons that need to move beyond the
standard event loop. Addon authors are encouraged to think about how to
avoid blocking the event loop with I/O or other time-intensive tasks by
off-loading work via libuv to non-blocking system operations, worker threads
or a custom use of libuv's threads.

- Internal Node.js libraries. Node.js itself exports a number of C++ APIs
that Addons can use &mdash; the most important of which is the
`node::ObjectWrap` class.

- Node.js includes a number of other statically linked libraries including
OpenSSL. These other libraries are located in the `deps/` directory in the
Node.js source tree. Only the libuv, OpenSSL, V8 and zlib symbols are
purposefully re-exported by Node.js and may be used to various extents by
Addons.
See [Linking to Node.js' own dependencies][] for additional information.
- V8: the C++ library Node.js currently uses to provide the
JavaScript implementation. V8 provides the mechanisms for creating objects,
calling functions, etc. V8's API is documented mostly in the
`v8.h` header file (`deps/v8/include/v8.h` in the Node.js source
tree), which is also available [online][v8-docs].

- [libuv][]: The C library that implements the Node.js event loop, its worker
threads and all of the asynchronous behaviors of the platform. It also
serves as a cross-platform abstraction library, giving easy, POSIX-like
access across all major operating systems to many common system tasks, such
as interacting with the filesystem, sockets, timers, and system events. libuv
also provides a pthreads-like threading abstraction that may be used to
power more sophisticated asynchronous Addons that need to move beyond the
standard event loop. Addon authors are encouraged to think about how to
avoid blocking the event loop with I/O or other time-intensive tasks by
off-loading work via libuv to non-blocking system operations, worker threads
or a custom use of libuv's threads.

- Internal Node.js libraries. Node.js itself exports a number of C++ APIs
that Addons can use &mdash; the most important of which is the
`node::ObjectWrap` class.

- Node.js includes a number of other statically linked libraries including
OpenSSL. These other libraries are located in the `deps/` directory in the
Node.js source tree. Only the libuv, OpenSSL, V8 and zlib symbols are
purposefully re-exported by Node.js and may be used to various extents by
Addons.
See [Linking to Node.js' own dependencies][] for additional information.

All of the following examples are available for [download][] and may
be used as the starting-point for an Addon.
Expand Down
10 changes: 5 additions & 5 deletions doc/api/buffer.md
Original file line number Diff line number Diff line change
Expand Up @@ -1363,11 +1363,11 @@ changes:

If `value` is:

* a string, `value` is interpreted according to the character encoding in
`encoding`.
* a `Buffer` or [`Uint8Array`][], `value` will be used in its entirety.
To compare a partial `Buffer`, use [`buf.slice()`][].
* a number, `value` will be interpreted as an unsigned 8-bit integer
* a string, `value` is interpreted according to the character encoding in
`encoding`.
* a `Buffer` or [`Uint8Array`][], `value` will be used in its entirety.
To compare a partial `Buffer`, use [`buf.slice()`][].
* a number, `value` will be interpreted as an unsigned 8-bit integer
value between `0` and `255`.

```js
Expand Down
26 changes: 13 additions & 13 deletions doc/api/child_process.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,19 +43,19 @@ and asynchronous alternatives to [`child_process.spawn()`][] and
[`child_process.spawnSync()`][]. Each of these alternatives are implemented on
top of [`child_process.spawn()`][] or [`child_process.spawnSync()`][].

* [`child_process.exec()`][]: spawns a shell and runs a command within that
shell, passing the `stdout` and `stderr` to a callback function when
complete.
* [`child_process.execFile()`][]: similar to [`child_process.exec()`][] except
that it spawns the command directly without first spawning a shell by
default.
* [`child_process.fork()`][]: spawns a new Node.js process and invokes a
specified module with an IPC communication channel established that allows
sending messages between parent and child.
* [`child_process.execSync()`][]: a synchronous version of
[`child_process.exec()`][] that will block the Node.js event loop.
* [`child_process.execFileSync()`][]: a synchronous version of
[`child_process.execFile()`][] that will block the Node.js event loop.
* [`child_process.exec()`][]: spawns a shell and runs a command within that
shell, passing the `stdout` and `stderr` to a callback function when
complete.
* [`child_process.execFile()`][]: similar to [`child_process.exec()`][] except
that it spawns the command directly without first spawning a shell by
default.
* [`child_process.fork()`][]: spawns a new Node.js process and invokes a
specified module with an IPC communication channel established that allows
sending messages between parent and child.
* [`child_process.execSync()`][]: a synchronous version of
[`child_process.exec()`][] that will block the Node.js event loop.
* [`child_process.execFileSync()`][]: a synchronous version of
[`child_process.execFile()`][] that will block the Node.js event loop.

For certain use cases, such as automating shell scripts, the
[synchronous counterparts][] may be more convenient. In many cases, however,
Expand Down
103 changes: 52 additions & 51 deletions doc/api/n-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -4029,35 +4029,36 @@ napi_status napi_define_class(napi_env env,
napi_value* result);
```

- `[in] env`: The environment that the API is invoked under.
- `[in] utf8name`: Name of the JavaScript constructor function; this is
not required to be the same as the C++ class name, though it is recommended
for clarity.
- `[in] length`: The length of the `utf8name` in bytes, or `NAPI_AUTO_LENGTH`
if it is null-terminated.
- `[in] constructor`: Callback function that handles constructing instances
of the class. (This should be a static method on the class, not an actual
C++ constructor function.)
- `[in] data`: Optional data to be passed to the constructor callback as
the `data` property of the callback info.
- `[in] property_count`: Number of items in the `properties` array argument.
- `[in] properties`: Array of property descriptors describing static and
instance data properties, accessors, and methods on the class
See `napi_property_descriptor`.
- `[out] result`: A `napi_value` representing the constructor function for
the class.
- `[in] env`: The environment that the API is invoked under.
- `[in] utf8name`: Name of the JavaScript constructor function; this is
not required to be the same as the C++ class name, though it is recommended
for clarity.
- `[in] length`: The length of the `utf8name` in bytes, or `NAPI_AUTO_LENGTH`
if it is null-terminated.
- `[in] constructor`: Callback function that handles constructing instances
of the class. (This should be a static method on the class, not an actual
C++ constructor function.)
- `[in] data`: Optional data to be passed to the constructor callback as
the `data` property of the callback info.
- `[in] property_count`: Number of items in the `properties` array argument.
- `[in] properties`: Array of property descriptors describing static and
instance data properties, accessors, and methods on the class
See `napi_property_descriptor`.
- `[out] result`: A `napi_value` representing the constructor function for
the class.

Returns `napi_ok` if the API succeeded.

Defines a JavaScript class that corresponds to a C++ class, including:
- A JavaScript constructor function that has the class name and invokes the
provided C++ constructor callback.
- Properties on the constructor function corresponding to _static_ data
properties, accessors, and methods of the C++ class (defined by
property descriptors with the `napi_static` attribute).
- Properties on the constructor function's `prototype` object corresponding to
_non-static_ data properties, accessors, and methods of the C++ class
(defined by property descriptors without the `napi_static` attribute).

- A JavaScript constructor function that has the class name and invokes the
provided C++ constructor callback.
- Properties on the constructor function corresponding to _static_ data
properties, accessors, and methods of the C++ class (defined by
property descriptors with the `napi_static` attribute).
- Properties on the constructor function's `prototype` object corresponding to
_non-static_ data properties, accessors, and methods of the C++ class
(defined by property descriptors without the `napi_static` attribute).

The C++ constructor callback should be a static method on the class that calls
the actual class constructor, then wraps the new C++ instance in a JavaScript
Expand Down Expand Up @@ -4091,16 +4092,16 @@ napi_status napi_wrap(napi_env env,
napi_ref* result);
```
- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The JavaScript object that will be the wrapper for the
native object.
- `[in] native_object`: The native instance that will be wrapped in the
JavaScript object.
- `[in] finalize_cb`: Optional native callback that can be used to free the
native instance when the JavaScript object is ready for garbage-collection.
- `[in] finalize_hint`: Optional contextual hint that is passed to the
finalize callback.
- `[out] result`: Optional reference to the wrapped object.
- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The JavaScript object that will be the wrapper for the
native object.
- `[in] native_object`: The native instance that will be wrapped in the
JavaScript object.
- `[in] finalize_cb`: Optional native callback that can be used to free the
native instance when the JavaScript object is ready for garbage-collection.
- `[in] finalize_hint`: Optional contextual hint that is passed to the
finalize callback.
- `[out] result`: Optional reference to the wrapped object.
Returns `napi_ok` if the API succeeded.
Expand Down Expand Up @@ -4145,9 +4146,9 @@ napi_status napi_unwrap(napi_env env,
void** result);
```

- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The object associated with the native instance.
- `[out] result`: Pointer to the wrapped native instance.
- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The object associated with the native instance.
- `[out] result`: Pointer to the wrapped native instance.

Returns `napi_ok` if the API succeeded.

Expand All @@ -4172,9 +4173,9 @@ napi_status napi_remove_wrap(napi_env env,
void** result);
```
- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The object associated with the native instance.
- `[out] result`: Pointer to the wrapped native instance.
- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The object associated with the native instance.
- `[out] result`: Pointer to the wrapped native instance.
Returns `napi_ok` if the API succeeded.
Expand All @@ -4200,16 +4201,16 @@ napi_status napi_add_finalizer(napi_env env,
napi_ref* result);
```

- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The JavaScript object to which the native data will be
attached.
- `[in] native_object`: The native data that will be attached to the JavaScript
object.
- `[in] finalize_cb`: Native callback that will be used to free the
native data when the JavaScript object is ready for garbage-collection.
- `[in] finalize_hint`: Optional contextual hint that is passed to the
finalize callback.
- `[out] result`: Optional reference to the JavaScript object.
- `[in] env`: The environment that the API is invoked under.
- `[in] js_object`: The JavaScript object to which the native data will be
attached.
- `[in] native_object`: The native data that will be attached to the JavaScript
object.
- `[in] finalize_cb`: Native callback that will be used to free the
native data when the JavaScript object is ready for garbage-collection.
- `[in] finalize_hint`: Optional contextual hint that is passed to the
finalize callback.
- `[out] result`: Optional reference to the JavaScript object.

Returns `napi_ok` if the API succeeded.

Expand Down
22 changes: 11 additions & 11 deletions doc/api/repl.md
Original file line number Diff line number Diff line change
Expand Up @@ -601,17 +601,17 @@ undefined
Various behaviors of the Node.js REPL can be customized using the following
environment variables:

- `NODE_REPL_HISTORY` - When a valid path is given, persistent REPL history
will be saved to the specified file rather than `.node_repl_history` in the
user's home directory. Setting this value to `''` (an empty string) will
disable persistent REPL history. Whitespace will be trimmed from the value.
On Windows platforms environment variables with empty values are invalid so
set this variable to one or more spaces to disable persistent REPL history.
- `NODE_REPL_HISTORY_SIZE` - Controls how many lines of history will be
persisted if history is available. Must be a positive number.
**Default:** `1000`.
- `NODE_REPL_MODE` - May be either `'sloppy'` or `'strict'`. **Default:**
`'sloppy'`, which will allow non-strict mode code to be run.
- `NODE_REPL_HISTORY` - When a valid path is given, persistent REPL history
will be saved to the specified file rather than `.node_repl_history` in the
user's home directory. Setting this value to `''` (an empty string) will
disable persistent REPL history. Whitespace will be trimmed from the value.
On Windows platforms environment variables with empty values are invalid so
set this variable to one or more spaces to disable persistent REPL history.
- `NODE_REPL_HISTORY_SIZE` - Controls how many lines of history will be
persisted if history is available. Must be a positive number.
**Default:** `1000`.
- `NODE_REPL_MODE` - May be either `'sloppy'` or `'strict'`. **Default:**
`'sloppy'`, which will allow non-strict mode code to be run.

### Persistent History

Expand Down

0 comments on commit 27a57d3

Please sign in to comment.