fix linter errors

Author: taniishkaaa

doc/api/packages.md

@@ -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
@@ -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
@@ -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
@@ -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).
@@ -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
@@ -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
@@ -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.
@@ -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"`
@@ -1071,7 +1071,7 @@ changes:
     description: Remove the `--experimental-resolve-self` option.
 -->
 
-- Type: {string}
+* Type: {string}
 
 ```json
 {
@@ -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
 {
@@ -1124,7 +1124,7 @@ added:
 
 > Stability: 1 - Experimental
 
-- Type: {string}
+* Type: {string}
 
 ```json
 {
@@ -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.
@@ -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
@@ -1226,7 +1226,7 @@ changes:
     description: Implement conditional exports.
 -->
 
-- Type: {Object} | {string} | {string\[]}
+* Type: {Object} | {string} | {string\[]}
 
 ```json
 {
@@ -1255,7 +1255,7 @@ added:
  - v12.19.0
 -->
 
-- Type: {Object}
+* Type: {Object}
 
 ```json
 // package.json