Skip to content

Commit

Permalink
fix linter errors
Browse files Browse the repository at this point in the history
  • Loading branch information
taniishkaaa committed Jul 31, 2024
1 parent cf0ba8e commit fedcd73
Showing 1 changed file with 56 additions and 56 deletions.
112 changes: 56 additions & 56 deletions doc/api/packages.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,12 +61,12 @@ Node.js will treat the following as [ES modules][] when passed to `node` as the
initial input, or when referenced by `import` statements or `import()`
expressions:

- Files with an `.mjs` extension.
* Files with an `.mjs` extension.

- Files with a `.js` extension when the nearest parent `package.json` file
* Files with a `.js` extension when the nearest parent `package.json` file
contains a top-level [`"type"`][] field with a value of `"module"`.

- Strings passed in as an argument to `--eval`, or piped to `node` via `STDIN`,
* Strings passed in as an argument to `--eval`, or piped to `node` via `STDIN`,
with the flag `--input-type=module`.

* Code containing syntax only successfully parsed as [ES modules][], such as
Expand All @@ -82,28 +82,28 @@ Node.js will treat the following as [CommonJS][] when passed to `node` as the
initial input, or when referenced by `import` statements or `import()`
expressions:

- Files with a `.cjs` extension.
* Files with a `.cjs` extension.

- Files with a `.js` extension when the nearest parent `package.json` file
* Files with a `.js` extension when the nearest parent `package.json` file
contains a top-level field [`"type"`][] with a value of `"commonjs"`.

- Strings passed in as an argument to `--eval` or `--print`, or piped to `node`
* Strings passed in as an argument to `--eval` or `--print`, or piped to `node`
via `STDIN`, with the flag `--input-type=commonjs`.

Aside from these explicit cases, there are other cases where Node.js defaults to
one module system or the other based on the value of the
[`--experimental-default-type`][] flag:

- Files ending in `.js` or with no extension, if there is no `package.json` file
* Files ending in `.js` or with no extension, if there is no `package.json` file
present in the same folder or any parent folder.

- Files ending in `.js` or with no extension, if the nearest parent
* Files ending in `.js` or with no extension, if the nearest parent
`package.json` field lacks a `"type"` field; unless the folder is inside a
`node_modules` folder. (Package scopes under `node_modules` are always treated
as CommonJS when the `package.json` file lacks a `"type"` field, regardless
of `--experimental-default-type`, for backward compatibility.)

- Strings passed in as an argument to `--eval` or piped to `node` via `STDIN`,
* Strings passed in as an argument to `--eval` or piped to `node` via `STDIN`,
when `--input-type` is unspecified.

This flag currently defaults to `"commonjs"`, but it may change in the future to
Expand Down Expand Up @@ -159,37 +159,37 @@ Node.js has two systems for resolving a specifier and loading modules.

There is the CommonJS module loader:

- It is fully synchronous.
- It is responsible for handling `require()` calls.
- It is monkey patchable.
- It supports [folders as modules][].
- When resolving a specifier, if no exact match is found, it will try to add
* It is fully synchronous.
* It is responsible for handling `require()` calls.
* It is monkey patchable.
* It supports [folders as modules][].
* When resolving a specifier, if no exact match is found, it will try to add
extensions (`.js`, `.json`, and finally `.node`) and then attempt to resolve
[folders as modules][].
- It treats `.json` as JSON text files.
- `.node` files are interpreted as compiled addon modules loaded with
* It treats `.json` as JSON text files.
* `.node` files are interpreted as compiled addon modules loaded with
`process.dlopen()`.
- It treats all files that lack `.json` or `.node` extensions as JavaScript
* It treats all files that lack `.json` or `.node` extensions as JavaScript
text files.
- It can only be used to [load ECMASCript modules from CommonJS modules][] if
* It can only be used to [load ECMASCript modules from CommonJS modules][] if
the module graph is synchronous (that contains no top-level `await`) when
`--experimental-require-module` is enabled.
When used to load a JavaScript text file that is not an ECMAScript module,
the file will be loaded as a CommonJS module.

There is the ECMAScript module loader:

- It is asynchronous, unless it's being used to load modules for `require()`.
- It is responsible for handling `import` statements and `import()` expressions.
- It is not monkey patchable, can be customized using [loader hooks][].
- It does not support folders as modules, directory indexes (e.g.
* It is asynchronous, unless it's being used to load modules for `require()`.
* It is responsible for handling `import` statements and `import()` expressions.
* It is not monkey patchable, can be customized using [loader hooks][].
* It does not support folders as modules, directory indexes (e.g.
`'./startup/index.js'`) must be fully specified.
- It does no extension searching. A file extension must be provided
* It does no extension searching. A file extension must be provided
when the specifier is a relative or absolute file URL.
- It can load JSON modules, but an import type attribute is required.
- It accepts only `.js`, `.mjs`, and `.cjs` extensions for JavaScript text
* It can load JSON modules, but an import type attribute is required.
* It accepts only `.js`, `.mjs`, and `.cjs` extensions for JavaScript text
files.
- It can be used to load JavaScript CommonJS modules. Such modules
* It can be used to load JavaScript CommonJS modules. Such modules
are passed through the `cjs-module-lexer` to try to identify named exports,
which are available if they can be determined through static analysis.
Imported CommonJS modules have their URLs converted to absolute
Expand Down Expand Up @@ -241,12 +241,12 @@ import 'commonjs-package/src/index.mjs';
The `.mjs` and `.cjs` extensions can be used to mix types within the same
package:

- Within a `"type": "module"` package, Node.js can be instructed to
* Within a `"type": "module"` package, Node.js can be instructed to
interpret a particular file as [CommonJS][] by naming it with a `.cjs`
extension (since both `.js` and `.mjs` files are treated as ES modules within
a `"module"` package).

- Within a `"type": "commonjs"` package, Node.js can be instructed to
* Within a `"type": "commonjs"` package, Node.js can be instructed to
interpret a particular file as an [ES module][] by naming it with an `.mjs`
extension (since both `.js` and `.cjs` files are treated as CommonJS within a
`"commonjs"` package).
Expand Down Expand Up @@ -647,25 +647,25 @@ For example, a package that wants to provide different ES module exports for
Node.js implements the following conditions, listed in order from most
specific to least specific as conditions should be defined:

- `"node-addons"` - similar to `"node"` and matches for any Node.js environment.
* `"node-addons"` - similar to `"node"` and matches for any Node.js environment.
This condition can be used to provide an entry point which uses native C++
addons as opposed to an entry point which is more universal and doesn't rely
on native addons. This condition can be disabled via the
[`--no-addons` flag][].
- `"node"` - matches for any Node.js environment. Can be a CommonJS or ES
* `"node"` - matches for any Node.js environment. Can be a CommonJS or ES
module file. _In most cases explicitly calling out the Node.js platform is
not necessary._
- `"import"` - matches when the package is loaded via `import` or
* `"import"` - matches when the package is loaded via `import` or
`import()`, or via any top-level import or resolve operation by the
ECMAScript module loader. Applies regardless of the module format of the
target file. _Always mutually exclusive with `"require"`._
- `"require"` - matches when the package is loaded via `require()`. The
* `"require"` - matches when the package is loaded via `require()`. The
referenced file should be loadable with `require()` although the condition
matches regardless of the module format of the target file. Expected
formats include CommonJS, JSON, native addons, and ES modules
if `--experimental-require-module` is enabled. _Always mutually
exclusive with `"import"`._
- `"default"` - the generic fallback that always matches. Can be a CommonJS
* `"default"` - the generic fallback that always matches. Can be a CommonJS
or ES module file. _This condition should always come last._

Within the [`"exports"`][] object, key order is significant. During condition
Expand Down Expand Up @@ -766,14 +766,14 @@ Since custom package conditions require clear definitions to ensure correct
usage, a list of common known package conditions and their strict definitions
is provided below to assist with ecosystem coordination.

- `"types"` - can be used by typing systems to resolve the typing file for
* `"types"` - can be used by typing systems to resolve the typing file for
the given export. _This condition should always be included first._
- `"browser"` - any web browser environment.
- `"development"` - can be used to define a development-only environment
* `"browser"` - any web browser environment.
* `"development"` - can be used to define a development-only environment
entry point, for example to provide additional debugging context such as
better error messages when running in a development mode. _Must always be
mutually exclusive with `"production"`._
- `"production"` - can be used to define a production environment entry
* `"production"` - can be used to define a production environment entry
point. _Must always be mutually exclusive with `"development"`._

For other runtimes, platform-specific condition key definitions are maintained
Expand All @@ -783,16 +783,16 @@ New conditions definitions may be added to this list by creating a pull request
to the [Node.js documentation for this section][]. The requirements for listing
a new condition definition here are that:

- The definition should be clear and unambiguous for all implementers.
- The use case for why the condition is needed should be clearly justified.
- There should exist sufficient existing implementation usage.
- The condition name should not conflict with another condition definition or
* The definition should be clear and unambiguous for all implementers.
* The use case for why the condition is needed should be clearly justified.
* There should exist sufficient existing implementation usage.
* The condition name should not conflict with another condition definition or
condition in wide usage.
- The listing of the condition definition should provide a coordination
* The listing of the condition definition should provide a coordination
benefit to the ecosystem that wouldn't otherwise be possible. For example,
this would not necessarily be the case for company-specific or
application-specific conditions.
- The condition should be such that a Node.js user would expect it to be in
* The condition should be such that a Node.js user would expect it to be in
Node.js core documentation. The `"types"` condition is a good example: It
doesn't really belong in the [Runtime Keys][] proposal but is a good fit
here in the Node.js docs.
Expand Down Expand Up @@ -1044,17 +1044,17 @@ additional fields which are ignored by Node.js and not documented here.

The following fields in `package.json` files are used in Node.js:

- [`"name"`][] - Relevant when using named imports within a package. Also used
* [`"name"`][] - Relevant when using named imports within a package. Also used
by package managers as the name of the package.
- [`"main"`][] - The default module when loading the package, if exports is not
* [`"main"`][] - The default module when loading the package, if exports is not
specified, and in versions of Node.js prior to the introduction of exports.
- [`"packageManager"`][] - The package manager recommended when contributing to
* [`"packageManager"`][] - The package manager recommended when contributing to
the package. Leveraged by the [Corepack][] shims.
- [`"type"`][] - The package type determining whether to load `.js` files as
* [`"type"`][] - The package type determining whether to load `.js` files as
CommonJS or ES modules.
- [`"exports"`][] - Package exports and conditional exports. When present,
* [`"exports"`][] - Package exports and conditional exports. When present,
limits which submodules can be loaded from within the package.
- [`"imports"`][] - Package imports, for use by modules within the package
* [`"imports"`][] - Package imports, for use by modules within the package
itself.

### `"name"`
Expand All @@ -1071,7 +1071,7 @@ changes:
description: Remove the `--experimental-resolve-self` option.
-->

- Type: {string}
* Type: {string}

```json
{
Expand All @@ -1092,7 +1092,7 @@ The `"name"` field can be used in addition to the [`"exports"`][] field to
added: v0.4.0
-->

- Type: {string}
* Type: {string}

```json
{
Expand Down Expand Up @@ -1124,7 +1124,7 @@ added:

> Stability: 1 - Experimental
- Type: {string}
* Type: {string}

```json
{
Expand Down Expand Up @@ -1153,7 +1153,7 @@ changes:
description: Unflag `--experimental-modules`.
-->

- Type: {string}
* Type: {string}

The `"type"` field defines the module format that Node.js uses for all
`.js` files that have that `package.json` file as their nearest parent.
Expand All @@ -1164,7 +1164,7 @@ Files ending with `.js` are loaded as ES modules when the nearest parent

The nearest parent `package.json` is defined as the first `package.json` found
when searching in the current folder, that folder's parent, and so on up
until a node_modules folder or the volume root is reached.
until a node\_modules folder or the volume root is reached.

```json
// package.json
Expand Down Expand Up @@ -1226,7 +1226,7 @@ changes:
description: Implement conditional exports.
-->

- Type: {Object} | {string} | {string\[]}
* Type: {Object} | {string} | {string\[]}

```json
{
Expand Down Expand Up @@ -1255,7 +1255,7 @@ added:
- v12.19.0
-->

- Type: {Object}
* Type: {Object}

```json
// package.json
Expand Down

0 comments on commit fedcd73

Please sign in to comment.