What happened to beta.13, beta.14, and beta.15? All unfortunately suffered
from problems that made it either impossible or unwise to upgrade to those
versions.
Packages published with node_modules unibuild properties that are
object-valued instead of string-valued cannot be loaded by the previous
version of meteor-tool, so the tool can't upgrade itself if any packages
have object-valued node_modules properties. Fortunately, no packages
currently exist that need both Npm.depends and local node_modules
directories, so we can just keep writing strings for now. At some point in
the future (maybe 1.3.1), we can assume people have upgraded to a version
of the tool that supports object-valued node_modules properties, and then
we can start writing those properties to disk without worrying about
old versions of the tool.
This reverts commit 99cb96fcf7.
Webpack already avoids this problem by transforming `require` to
`__webpack_require__`, and Browserify bundles can use something like
https://www.npmjs.com/package/derequire to rewrite ``require` calls to
avoid confusing other tools. False positives are acceptable, and we can
measure/mitigate the performance consequences in any number of ways.
Fixes#6427.
Fixes#6430.
- Split files into the correct place, given the guide
- Import html file
- Removed test [it's not a demo]
- Use ReactiveVar rather than Session
- Added an info section to guide people further
Packages published before the modules package existed may acquire a
dependency on the modules package upon upgrading to Meteor 1.3, because
they depended on the ecmascript package, which now implies the modules
package. If the previously published isopacket does not provide a
sourcePath or path property, then we should use the servePath property
instead. With that fix in place, I am now strictly enforcing that all
files scanned by the ImportScanner actually exist on disk.
Should fix#5871.
This analysis isn't perfect, but it addresses the biggest source of
dependency false positives, namely Browserify and Webpack bundles that
provide their own implementation of the require function.
Our old "unit" test mode didn't really enforce "unit-ness" and was perfectly capable of running integration test. So it was confusing to call the two modes unit and integration test modes.
Instead, we call them "test mode" and "full app test mode", run with `meteor test` and `meteor test --full-app`.
The rules for test files were also simplified -- simply *.test[s].* for test mode, and *.app-test[s].* for full app tests. `tests/` directories are simply ignored again.
