@@ -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
{
@@ -700,8 +700,8 @@ changes:
700
700
description: Unflag self-referencing a package using its name.
701
701
-->
702
702
703
- Within a package, the values defined in the package’ s
704
- ` package.json ` [ ` "exports" ` ] [ ] field can be referenced via the package’ s name.
703
+ Within a package, the values defined in the package' s
704
+ ` package.json ` [ ` "exports" ` ] [ ] field can be referenced via the package' s name.
705
705
For example, assuming the ` package.json ` is:
706
706
707
707
``` json
@@ -905,7 +905,7 @@ This approach is appropriate for any of the following use cases:
905
905
install both this package and those other packages. For example a ` utilities `
906
906
package is used directly in an application, and a ` utilities-plus ` package
907
907
adds a few more functions to ` utilities ` . Because the wrapper exports
908
- underlying CommonJS files, it doesn’ t matter if ` utilities-plus ` is written in
908
+ underlying CommonJS files, it doesn' t matter if ` utilities-plus ` is written in
909
909
CommonJS or ES module syntax; it will work either way.
910
910
* The package stores internal state, and the package author would prefer not to
911
911
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
915
915
version of the package. This could be used via ` import 'pkg/module' ` by users
916
916
who are certain that the CommonJS version will not be loaded anywhere in the
917
917
application, such as by dependencies; or if the CommonJS version can be loaded
918
- but doesn’ t affect the ES module version (for example, because the package is
918
+ but doesn' t affect the ES module version (for example, because the package is
919
919
stateless):
920
920
921
921
``` json
@@ -949,22 +949,22 @@ points directly:
949
949
950
950
This can be done if both the CommonJS and ES module versions of the package are
951
951
equivalent, for example because one is the transpiled output of the other; and
952
- the package’ s management of state is carefully isolated (or the package is
952
+ the package' s management of state is carefully isolated (or the package is
953
953
stateless).
954
954
955
955
The reason that state is an issue is because both the CommonJS and ES module
956
956
versions of the package might get used within an application; for example, the
957
- user’ s application code could ` import ` the ES module version while a dependency
957
+ user' s application code could ` import ` the ES module version while a dependency
958
958
` require ` s the CommonJS version. If that were to occur, two copies of the
959
959
package would be loaded in memory and therefore two separate states would be
960
960
present. This would likely cause hard-to-troubleshoot bugs.
961
961
962
- Aside from writing a stateless package (if JavaScript’ s ` Math ` were a package,
962
+ Aside from writing a stateless package (if JavaScript' s ` Math ` were a package,
963
963
for example, it would be stateless as all of its methods are static), there are
964
- some ways to isolate state so that it’ s shared between the potentially loaded
964
+ some ways to isolate state so that it' s shared between the potentially loaded
965
965
CommonJS and ES module instances of the package:
966
966
967
- 1 . If possible, contain all state within an instantiated object. JavaScript’ s
967
+ 1 . If possible, contain all state within an instantiated object. JavaScript' s
968
968
` Date ` , for example, needs to be instantiated to contain state; if it were a
969
969
package, it would be used like this:
970
970
@@ -974,7 +974,7 @@ CommonJS and ES module instances of the package:
974
974
// someDate contains state; Date does not
975
975
```
976
976
977
- The ` new ` keyword isn’ t required; a package’ s function can return a new
977
+ The ` new ` keyword isn' t required; a package' s function can return a new
978
978
object, or modify a passed-in object, to keep the state external to the
979
979
package.
980
980
@@ -1001,7 +1001,7 @@ CommonJS and ES module instances of the package:
1001
1001
each reference of ` pkg ` will contain the same state; and modifying that
1002
1002
state from either module system will apply to both.
1003
1003
1004
- Any plugins that attach to the package’ s singleton would need to separately
1004
+ Any plugins that attach to the package' s singleton would need to separately
1005
1005
attach to both the CommonJS and ES module singletons.
1006
1006
1007
1007
This approach is appropriate for any of the following use cases:
@@ -1076,7 +1076,7 @@ changes:
1076
1076
}
1077
1077
```
1078
1078
1079
- The ` "name" ` field defines your package’ s name. Publishing to the
1079
+ The ` "name" ` field defines your package' s name. Publishing to the
1080
1080
_ npm_ registry requires a name that satisfies
1081
1081
[ certain requirements] ( https://docs.npmjs.com/files/package.json#name ) .
1082
1082
@@ -1159,7 +1159,7 @@ Files ending with `.js` are loaded as ES modules when the nearest parent
1159
1159
` "module" ` .
1160
1160
1161
1161
The nearest parent ` package.json ` is defined as the first ` package.json ` found
1162
- when searching in the current folder, that folder’ s parent, and so on up
1162
+ when searching in the current folder, that folder' s parent, and so on up
1163
1163
until a node\_ modules folder or the volume root is reached.
1164
1164
1165
1165
``` json
0 commit comments