diff options
author | Tobias Nießen <tniessen@tnie.de> | 2022-05-17 22:04:51 +0300 |
---|---|---|
committer | Bryan English <bryan@bryanenglish.com> | 2022-05-30 19:33:48 +0300 |
commit | 4e9393e32f96812cc0a042fd1b6a431ef73b50aa (patch) | |
tree | f374c6642b234f07b9c7c0a2977f6ef9d85d2547 /doc/api/packages.md | |
parent | 3e89b7336dbdfb7bec601e52b49d63fa3a0105f4 (diff) |
doc: use ASCII apostrophes consistently
PR-URL: https://github.com/nodejs/node/pull/43114
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Diffstat (limited to 'doc/api/packages.md')
-rw-r--r-- | doc/api/packages.md | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/doc/api/packages.md b/doc/api/packages.md index 2271a1621b3..f5eadab6522 100644 --- a/doc/api/packages.md +++ b/doc/api/packages.md @@ -224,7 +224,7 @@ in your project's `package.json`. ## Package entry points -In a package’s `package.json` file, two fields can define entry points for a +In a package's `package.json` file, two fields can define entry points for a package: [`"main"`][] and [`"exports"`][]. The [`"main"`][] field is supported in all versions of Node.js, but its capabilities are limited: it only defines the main entry point of the package. @@ -255,7 +255,7 @@ likely be a breaking change.** To make the introduction of [`"exports"`][] non-breaking, ensure that every previously supported entry point is exported. It is best to explicitly specify -entry points so that the package’s public API is well-defined. For example, +entry points so that the package's public API is well-defined. For example, a project that previous exported `main`, `lib`, `feature`, and the `package.json` could use the following `package.exports`: @@ -303,7 +303,7 @@ path `import feature from 'my-mod/feature/index.js`. ### Main entry point export To set the main entry point for a package, it is advisable to define both -[`"exports"`][] and [`"main"`][] in the package’s [`package.json`][] file: +[`"exports"`][] and [`"main"`][] in the package's [`package.json`][] file: ```json { @@ -700,8 +700,8 @@ changes: description: Unflag self-referencing a package using its name. --> -Within a package, the values defined in the package’s -`package.json` [`"exports"`][] field can be referenced via the package’s name. +Within a package, the values defined in the package's +`package.json` [`"exports"`][] field can be referenced via the package's name. For example, assuming the `package.json` is: ```json @@ -905,7 +905,7 @@ This approach is appropriate for any of the following use cases: install both this package and those other packages. For example a `utilities` package is used directly in an application, and a `utilities-plus` package adds a few more functions to `utilities`. Because the wrapper exports - underlying CommonJS files, it doesn’t matter if `utilities-plus` is written in + underlying CommonJS files, it doesn't matter if `utilities-plus` is written in CommonJS or ES module syntax; it will work either way. * The package stores internal state, and the package author would prefer not to refactor the package to isolate its state management. See the next section. @@ -915,7 +915,7 @@ be to add an export, e.g. `"./module"`, to point to an all-ES module-syntax version of the package. This could be used via `import 'pkg/module'` by users who are certain that the CommonJS version will not be loaded anywhere in the application, such as by dependencies; or if the CommonJS version can be loaded -but doesn’t affect the ES module version (for example, because the package is +but doesn't affect the ES module version (for example, because the package is stateless): ```json @@ -949,22 +949,22 @@ points directly: This can be done if both the CommonJS and ES module versions of the package are equivalent, for example because one is the transpiled output of the other; and -the package’s management of state is carefully isolated (or the package is +the package's management of state is carefully isolated (or the package is stateless). The reason that state is an issue is because both the CommonJS and ES module versions of the package might get used within an application; for example, the -user’s application code could `import` the ES module version while a dependency +user's application code could `import` the ES module version while a dependency `require`s the CommonJS version. If that were to occur, two copies of the package would be loaded in memory and therefore two separate states would be present. This would likely cause hard-to-troubleshoot bugs. -Aside from writing a stateless package (if JavaScript’s `Math` were a package, +Aside from writing a stateless package (if JavaScript's `Math` were a package, for example, it would be stateless as all of its methods are static), there are -some ways to isolate state so that it’s shared between the potentially loaded +some ways to isolate state so that it's shared between the potentially loaded CommonJS and ES module instances of the package: -1. If possible, contain all state within an instantiated object. JavaScript’s +1. If possible, contain all state within an instantiated object. JavaScript's `Date`, for example, needs to be instantiated to contain state; if it were a package, it would be used like this: @@ -974,7 +974,7 @@ CommonJS and ES module instances of the package: // someDate contains state; Date does not ``` - The `new` keyword isn’t required; a package’s function can return a new + The `new` keyword isn't required; a package's function can return a new object, or modify a passed-in object, to keep the state external to the package. @@ -1001,7 +1001,7 @@ CommonJS and ES module instances of the package: each reference of `pkg` will contain the same state; and modifying that state from either module system will apply to both. -Any plugins that attach to the package’s singleton would need to separately +Any plugins that attach to the package's singleton would need to separately attach to both the CommonJS and ES module singletons. This approach is appropriate for any of the following use cases: @@ -1076,7 +1076,7 @@ changes: } ``` -The `"name"` field defines your package’s name. Publishing to the +The `"name"` field defines your package's name. Publishing to the _npm_ registry requires a name that satisfies [certain requirements](https://docs.npmjs.com/files/package.json#name). @@ -1159,7 +1159,7 @@ Files ending with `.js` are loaded as ES modules when the nearest parent `"module"`. 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 +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. ```json |