@@ -224,7 +224,7 @@ in your project's `package.json`.
224
224
225
225
## Package entry points
226
226
227
- In a package’ s ` package.json ` file, two fields can define entry points for a
227
+ In a package' s ` package.json ` file, two fields can define entry points for a
228
228
package: [ ` "main" ` ] [ ] and [ ` "exports" ` ] [ ] . The [ ` "main" ` ] [ ] field is supported
229
229
in all versions of Node.js, but its capabilities are limited: it only defines
230
230
the main entry point of the package.
@@ -255,7 +255,7 @@ likely be a breaking change.**
255
255
256
256
To make the introduction of [ ` "exports" ` ] [ ] non-breaking, ensure that every
257
257
previously supported entry point is exported. It is best to explicitly specify
258
- entry points so that the package’ s public API is well-defined. For example,
258
+ entry points so that the package' s public API is well-defined. For example,
259
259
a project that previous exported ` main ` , ` lib ` ,
260
260
` feature ` , and the ` package.json ` could use the following ` package.exports ` :
261
261
@@ -303,7 +303,7 @@ path `import feature from 'my-mod/feature/index.js`.
303
303
### Main entry point export
304
304
305
305
To set the main entry point for a package, it is advisable to define both
306
- [ ` "exports" ` ] [ ] and [ ` "main" ` ] [ ] in the package’ s [ ` package.json ` ] [ ] file:
306
+ [ ` "exports" ` ] [ ] and [ ` "main" ` ] [ ] in the package' s [ ` package.json ` ] [ ] file:
307
307
308
308
``` json
309
309
{
@@ -745,8 +745,8 @@ changes:
745
745
description: Unflag self-referencing a package using its name.
746
746
-->
747
747
748
- Within a package, the values defined in the package’ s
749
- ` package.json ` [ ` "exports" ` ] [ ] field can be referenced via the package’ s name.
748
+ Within a package, the values defined in the package' s
749
+ ` package.json ` [ ` "exports" ` ] [ ] field can be referenced via the package' s name.
750
750
For example, assuming the ` package.json ` is:
751
751
752
752
``` json
@@ -950,7 +950,7 @@ This approach is appropriate for any of the following use cases:
950
950
install both this package and those other packages. For example a ` utilities `
951
951
package is used directly in an application, and a ` utilities-plus ` package
952
952
adds a few more functions to ` utilities ` . Because the wrapper exports
953
- underlying CommonJS files, it doesn’ t matter if ` utilities-plus ` is written in
953
+ underlying CommonJS files, it doesn' t matter if ` utilities-plus ` is written in
954
954
CommonJS or ES module syntax; it will work either way.
955
955
* The package stores internal state, and the package author would prefer not to
956
956
refactor the package to isolate its state management. See the next section.
@@ -960,7 +960,7 @@ be to add an export, e.g. `"./module"`, to point to an all-ES module-syntax
960
960
version of the package. This could be used via ` import 'pkg/module' ` by users
961
961
who are certain that the CommonJS version will not be loaded anywhere in the
962
962
application, such as by dependencies; or if the CommonJS version can be loaded
963
- but doesn’ t affect the ES module version (for example, because the package is
963
+ but doesn' t affect the ES module version (for example, because the package is
964
964
stateless):
965
965
966
966
``` json
@@ -994,22 +994,22 @@ points directly:
994
994
995
995
This can be done if both the CommonJS and ES module versions of the package are
996
996
equivalent, for example because one is the transpiled output of the other; and
997
- the package’ s management of state is carefully isolated (or the package is
997
+ the package' s management of state is carefully isolated (or the package is
998
998
stateless).
999
999
1000
1000
The reason that state is an issue is because both the CommonJS and ES module
1001
1001
versions of the package might get used within an application; for example, the
1002
- user’ s application code could ` import ` the ES module version while a dependency
1002
+ user' s application code could ` import ` the ES module version while a dependency
1003
1003
` require ` s the CommonJS version. If that were to occur, two copies of the
1004
1004
package would be loaded in memory and therefore two separate states would be
1005
1005
present. This would likely cause hard-to-troubleshoot bugs.
1006
1006
1007
- Aside from writing a stateless package (if JavaScript’ s ` Math ` were a package,
1007
+ Aside from writing a stateless package (if JavaScript' s ` Math ` were a package,
1008
1008
for example, it would be stateless as all of its methods are static), there are
1009
- some ways to isolate state so that it’ s shared between the potentially loaded
1009
+ some ways to isolate state so that it' s shared between the potentially loaded
1010
1010
CommonJS and ES module instances of the package:
1011
1011
1012
- 1 . If possible, contain all state within an instantiated object. JavaScript’ s
1012
+ 1 . If possible, contain all state within an instantiated object. JavaScript' s
1013
1013
` Date ` , for example, needs to be instantiated to contain state; if it were a
1014
1014
package, it would be used like this:
1015
1015
@@ -1019,7 +1019,7 @@ CommonJS and ES module instances of the package:
1019
1019
// someDate contains state; Date does not
1020
1020
```
1021
1021
1022
- The ` new ` keyword isn’ t required; a package’ s function can return a new
1022
+ The ` new ` keyword isn' t required; a package' s function can return a new
1023
1023
object, or modify a passed-in object, to keep the state external to the
1024
1024
package.
1025
1025
@@ -1046,7 +1046,7 @@ CommonJS and ES module instances of the package:
1046
1046
each reference of ` pkg ` will contain the same state; and modifying that
1047
1047
state from either module system will apply to both.
1048
1048
1049
- Any plugins that attach to the package’ s singleton would need to separately
1049
+ Any plugins that attach to the package' s singleton would need to separately
1050
1050
attach to both the CommonJS and ES module singletons.
1051
1051
1052
1052
This approach is appropriate for any of the following use cases:
@@ -1121,7 +1121,7 @@ changes:
1121
1121
}
1122
1122
```
1123
1123
1124
- The ` "name" ` field defines your package’ s name. Publishing to the
1124
+ The ` "name" ` field defines your package' s name. Publishing to the
1125
1125
_ npm_ registry requires a name that satisfies
1126
1126
[ certain requirements] ( https://docs.npmjs.com/files/package.json#name ) .
1127
1127
@@ -1202,7 +1202,7 @@ Files ending with `.js` are loaded as ES modules when the nearest parent
1202
1202
` "module" ` .
1203
1203
1204
1204
The nearest parent ` package.json ` is defined as the first ` package.json ` found
1205
- when searching in the current folder, that folder’ s parent, and so on up
1205
+ when searching in the current folder, that folder' s parent, and so on up
1206
1206
until a node\_ modules folder or the volume root is reached.
1207
1207
1208
1208
``` json
0 commit comments