Previously, when building a JavaScript bundle for the client, if a
package.json file had a string-valued "browser" field, we would replace
the value of the "main" field of the bundled package.json module with the
value of the "browser" field. This trick was important because it allowed
an npm package to have a different entry point on the client than it had
on the server.
However, that approach became inconsistent if the package.json file was
also explicitly imported as a module, because the package.json stub used
for module resolution prevented the real contents of package.json from
getting bundled, and disagreed with the original package.json module about
the value of the "main" field.
To resolve that inconsistency, it seems better to avoid modifying the
"main" field of package.json modules, and instead rely on the runtime
module system to make sense of the "browser" field, regardless of whether
the package.json module is a stub used only for module resolution or
contains the full contents of the original package.json file.
The ability to understand "browser" fields of package.json modules was
introduced in install@0.8.3:
377d1a3b51
This is potentially a backwards-incompatible change for developers using
this version of `ImportScanner` and `Resolver` who have not yet upgraded
their `modules-runtime` package to at least version 0.7.8. The solution is
to upgrade `modules-runtime`, though it would be nice to enforce that
better somehow.
If you call api.mainModule(path, where, { lazy: true }), that main
module will not be evaluated until other code imports it at runtime, and
won't even be bundled if no other code imports it.
Closes#6132.
The options.transformFilename function is only supposed to transform
target file names, not the names of source files to be copied.
This behavior was broken by c5809a4a1c
between Meteor 1.4.0.1 and 1.4.1. Thank goodness for `git bisect`!
The biggest symptom of this mistake was that `meteor create --package`
no longer created files based on the ~fs-name~.js and ~fs-name~-tests.js
template files.
This probably merits a 1.4.1.4 release in addition to 1.4.2.2.
Scaffold an official project structure
Add --bare option to meteor create
Notice scaffold options on meteor create
add full skeleton
add spaces
remove shell-server package from skew-full + add description of new packages
Add --bare option to meteor create
Notice scaffold options on meteor create
add full skeleton
add spaces
remove shell-server package from skew-full + add description of new packages
improve PR
resolve conflict
Fix rebase
fix static-assets readme
Fix tipo
Remove insecure and auto publish packages
Remove useraccounts-configuration.js
add tests
fix PR
This is another way to fix the bug I previously fixed by passing
options.allowSyntaxError to optimisticReadJsonOrNull.
To reproduce the bug (and/or verify that it is fixed), run the following
commands in a terminal:
rm -rf meteor/packages/npm-mongo/.npm
meteor/meteor --get-ready
Before these two commits, optimisticReadJsonOrNull would throw a
SyntaxError when reading one of the .meteor-portable files because an
asynchronous write to the same file had not yet finished.
