You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+8-5Lines changed: 8 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@
13
13
14
14
This ensures 100% backward-compatibility, while still allowing some freedom of design.
15
15
16
-
**2. Instead of "index.js", the entry point for ES modules is "default.js", or instead of a package.json "main", "module" is used.**
16
+
**2. Instead of "index.js", the entry point for ES modules is "default.js", or instead of a package.json "main", "default" is used.**
17
17
18
18
A distinct entry point ("default.js") allows us to distinguish when a user is attempting to import from a legacy package or a folder containing CommonJS modules.
19
19
@@ -51,7 +51,7 @@ Since there is no change to the behavior of `require`, there is no change to the
51
51
52
52
### Supporting `import` for old-style packages
53
53
54
-
If a "default.js" file or "module" main does not exist in the package root, then it will be loaded as an old-style module with no further changes. It just works.
54
+
If a "default.js" file or "default" main does not exist in the package root, then it will be loaded as an old-style module with no further changes. It just works.
55
55
56
56
### Supporting `require` for ES Module packages
57
57
@@ -136,15 +136,15 @@ A common practice with old-style packages is to allow the user to `require` indi
136
136
var deepModule =require('foo/bar');
137
137
```
138
138
139
-
If the package author wants to support both `require`ing and `import`ing into a nested module, they can do so by creating a folder for each "deep link", which contains both an old-style and new-style entry point:
139
+
If the package author wants to support both `require`ing and `import`ing into a nested module, they might do so by creating a folder for each "deep link", which contains both an old-style and new-style entry point:
140
140
141
141
```
142
142
bar/
143
143
index.js (Entry point for require)
144
144
default.js (Entry point for import)
145
145
```
146
146
147
-
## Why "default.js"?
147
+
## Why "default"?
148
148
149
149
- "default.html" is frequently used as a folder entry point for web servers.
150
150
- The word "default" has a special, and similar meaning in ES modules.
@@ -154,6 +154,9 @@ In a [search of all the filenames in the @latest NPM packages as of 2016-01-28](
154
154
155
155
As a filename, "default.js" was found 1968 times.
156
156
157
+
> If when testing this proposal it turns out that using the package.json "module" property instead of "default" works in a large percentage of cases
158
+
of existing usage, then it could be considered to use `"default.js"` and `"module"` in the package.json file. But this would have to be based
159
+
on ensuring the tests have been run against common packages to verify that such compatibility will be supported.
157
160
158
161
## Running Modules from the Command Line
159
162
@@ -204,7 +207,7 @@ Loads _X_ from a module at path _Y_. _T_ is either "require" or "import".
204
207
1. If T is "import",
205
208
1. If X/default.js is a file, load X/default.js as ES module text. STOP
206
209
1. If X/package.json is a file,
207
-
1. Parse X/package.json, and look for "module" field.
210
+
1. Parse X/package.json, and look for "default" field.
208
211
1. load X/(json module field) as ES module text. STOP
209
212
1. NOTE: If neither of the above are a file, then fallback to legacy behavior
0 commit comments