This should shave down bundle sizes by 14.4 kb for many non-blaze projects.
The other core meteor packages have not depended on `underscore` since #9362. However, we are only able to remove this last dependency now due to the previous commit, which eliminated usages of `underscore` from apps that did not have the package listed in their `packages` files. This was causing CI test failures that now should be corrected.
Any meteor apps currently using `_` without `underscore` listed in their `packages` file will need to add the package explicitly.
Version number of `meteor-base` bumped from 1.3.0 to 1.4.0.
There are only a few uses of `underscore` in these apps, and two of them actually used `underscore` without having it explicitly listed in their `packages` file.
This is a problem, because the apps were relying on the dependency from `meteor-base`, which we want to remove to cut down bundle sizes.
For the `modules` test app, I've added `underscore` to the `packages` file, because it is using `_` in an assertion about the module system. For the other app and all other uses of `_`, rather than add `underscore` to the `packages` files, I took the modernization route and replaced the functions with their ES6 equivalents, and then removed `underscore` from all `packages` files.
In order for Meteor to maintain its commitment to being a
zero-configuration tool, any configuration options that we add must come
pre-configured in the best way possible for newly created apps.
In particular, the default new Meteor app must contain a reasonable
testing story, or else we are signalling to the community that testing is
an afterthought.
With that said, this PR is still a work in progress. I welcome your
feedback on how best to configure the default `meteor create` starter app.
Builds on #9690 and #9714.
Setting meteor.testModule is a great way to specify test entry points
explicitly, rather than relying on Meteor's isTestFilePath heuristics:
https://github.com/meteor/meteor/blob/devel/tools/isobuild/test-files.js
The syntax is identical to meteor.mainModule, so you can set an explicit
meteor.testModule.{client,server,...} for each platform. If a testModule
is not specified for a platform, then Meteor's existing rules about test
file paths apply for that platform, as before.
If a testModule is specified, that module will always be loaded eagerly
when running `meteor test`, in addition to any other modules that load
eagerly because of meteor.mainModule or other rules regarding module
loading. If you run `meteor test` without the `--full-app` option, then no
application JS modules other than the testModule (and any modules imported
by it) will be loaded eagerly.
If meteor.mainModule.{client,server,...} === false, no modules will be
loaded eagerly for that architecture. This is useful if you have an app
with no special app/{client,server} directory structure and you want to
specify an entry point for just the client (or just the server), without
accidentally loading everything on the other architecture.
Determining if Meteor package files should be loaded lazily or eagerly is
a lot easier than doing so for application files, so we should just do
that separately, to avoid any risk of application directory layout logic
interfering with package behavior.
https://github.com/meteor/meteor-feature-requests/issues/135
This change allows applications to specify specific entry points for each
architecture, without relying on `imports` directories to determine the
eagerness/laziness of modules. In other words, it will finally be possible
to build a Meteor app without a special `imports` directory.
Specifically, if `packageJson.meteor.mainModule[architecture]` is defined,
all modules for that architecture will be lazy except for the specified
module, which will be loaded eagerly.
Possible values for `architecture` include "client", "server", "web",
"web.browser", "web.cordova", "os", and so on, just like the second
argument to `api.mainModule(file, where)` in Meteor packages.
In order to match existing behavior, a Meteor application might include
the following in its `package.json` file:
"meteor": {
"mainModule": {
"client": "client/main.js",
"server": "server/main.js"
}
}
These architectures are handled independently, so omitting the "client" or
"server" property would cause that architecture to revert to standard
Meteor loading semantics. In other words, Meteor developers must opt into
this functionality, which is crucial for backwards compatibility.
Note that this functionality applies only to application modules, since
modules in Meteor packages are already lazy by default, and Meteor
packages can already specify entry points by calling `api.mainModule` in
their `package.js` files.
Also note that the loading behavior of non-JavaScript resources is *not*
affected by `packageJson.meteor.mainModule`. Only resources added by
compiler plugins via `addJavaScript` are subject to the new configuration
option. If a compiler plugin calls `addStylesheet` or `addHtml`, those
resources will still be included unconditionally in the HTML document
rendered by the web server. While you could try to import these resources
from JavaScript, you would only be importing any JavaScript resources the
compiler plugin registered using `addJavaScript`, and not the actual HTML
or CSS resources. I welcome feedback on this decision, but if there's no
meaningful way to import a resource, making it lazy just means it won't be
loaded at all.
An ulterior motive for this feature is to enable Meteor apps to have
directory layouts that developers who are not familiar with Meteor can
immediately understand. The special meaning of the `imports` directory and
the surprising eagerness of modules outside of `imports` have always
required some explanation, so this change should reduce that surprise.
Because Meteor strives to be a zero-configuration tool, this is currently
the only supported option in the "meteor" section of `package.json`,
though the available options may be expanded in the future if that's the
best/only way to solve important problems. This would involve adding
additional methods to the `MeteorConfig` class in `project-context.js`,
and then using those methods elsewhere in the `meteor/tools` codebase.
Many npm based packages provide supporting assets that need
to be made available, when used on the web. For example, to
use the `font-awesome` package properly, the
`node_modules/font-awesome/fonts` files need to be made accessible
to incoming web requests.
With Meteor, an easy way to handle this would be to create a
symlink to `node_modules/font-awesome/fonts` from within an
application's `/public` directory. This would then allow all
of `font-awesome`'s font files to be accessed directly by
incoming clients. Unfortunately, while this approach does work
in development when using the Meteor Tool, it does not work when
production bundles are created.
Meteor's isobuild process uses a helper class called
`SymlinkLoopChecker`, to make sure the build process doesn't get
caught up in an infinite loop trying to follow circular symlinks.
Currently, a shared `SymlinkLoopChecker` instance is used to watch
for symlink loops during both the `_findSoures` and `_findAssets`
parts of the isobuild process. `_findSources` is called first, and
covers source files that an application uses from the `node_modules`
directory. The `SymlinkLoopChecker` tracks all of the `node_modules`
directories covered, so they can be watched for in the future (to
prevent duplicate inclusions). Next, `_findAssets` is called using
the same `SymlinkLoopChecker`. This means that if there are any
`node_modules` symlinks used in the `public` or `private`
directories, they will be marked as being duplicates (and stripped),
since they were already covered in the `_findSources` run.
This commit changes things a bit so that both `_findSources` and
`_findAssets` use their own `SymlinkLoopChecker` instance. This
opens up an applications symlink capabilities a bit, while still
preserving some circular symlink safeguards. By doing this, a
production application bundle can now maintain the contents of
`node_modules` based symlinks, used in `public` and `private`.
So in the case of `font-awesome` for example
```
public/fonts --> ../node_modules/font-awesome/fonts
```
becomes the following in the production application bundle
```
bundle/programs/web.browser/app/fonts/[all fonts files]
```
Fixes#7013.
* Introduce MONGO_BIND_IP override
Introduces an environment variable (MONGO_BIND_IP) for overriding of meteor's mongod's `bind_ip` option to allow docker containers to bind on `0.0.0.0` to be able to expose mongod processs via docker's `-p 3001:3001` port bindings.
Related issue: https://serverfault.com/questions/758225/cannot-connect-to-mongodb-in-docker
Partially Related PR: https://github.com/meteor/meteor/pull/469
* Use METEOR_MONGO_BIND_IP over ambiguous MONGO_BIND_IP
Change request to use METEOR_MONGO_BIND_IP over ambiguous MONGO_BIND_IP
- This changes meteor deploy to poll the /version-status/ REST endpoint
in Galaxy for the build and deploy status of the returned version
- Also fixes up a typo in a test
- Currently only configured to use a default polling configuration
- This change also adds a flag called --no-wait which allows users to
specify that they want the deploy command to behave just as before
Console.isInteractive() will be false during our Circle CI test runs,
since we set the METEOR_HEADLESS environment variable, so this change
should help prevent spurious test failures like these:
https://circleci.com/gh/meteor/meteor/15305.
This should help with analyzing how much time computeJsOutputFilesMap
spends scanning imports within individual packages (scanImports) versus
resolving cross-package imports (scanMissingModules).
This reverts commit dfc0702558.
We've seen some odd test failures (e.g. `passwords - tokens`) and trouble
updating from 1.6.1 to 1.6.2-beta.3 (easily solved with `meteor reset`,
but also worth investigating), so I think we should keep working on the
Mongo 3.6 upgrade in a PR, rather than running all of our tests against
a devel branch that includes Mongo 3.6.
cc @abernix @hwillson
* Add a self-test skip option
Meteor's CI infrastructure is configured to exclude certain
`self-test`'s on each run. These excludes are specified in
each CI environment's config file, and included when running
`meteor self-test`. Developers running `meteor self-test`
locally however are not using these excludes by default,
so developer's have to manually look up the current exclude
list from one of the CI configs, then add these excludes to
their own `meteor self-test` call manually.
This commit adds a new `skip` option to Meteor's `self-test`
system, that can be used to skip adding/running a defined
`self-test` (similar in concept to Mocha's `skip` feature).
This provides a way to skip the running of older
`self-test`'s that are no longer needed, but allows them to
be preserved in the `self-test` suite, for future reference.
With this functionality in place, and the older test suites
updated to use it, Meteor's base CI excludes no longer need
to be maintained in their respective config files. The
excludes are all managed at the source (the test definition),
and can be leveraged by anyone/anything calling
`meteor self-test`.
* Log message describing skipped test
* Add manually-ignored count to self-test summary
* Small comment correction
* History.md entry with PR link
Update the Meteor Tool to use Mongo 3.6.2 for 64-bit OS'
and Mongo 3.2.18 for 32-bit OS'. A few important mentions:
- As of Mongo 3.6, all Mongo binary downloads include
SSL - there is no longer a non-SSL based download bundle
(so it's a bit bigger, but that shouldn't be an issue).
- Using the `--nojournal` option with WiredTiger based
replica sets is no longer supported (see
https://jira.mongodb.org/browse/SERVER-30760). The
`--nojournal` flag was added in
bcfe072d52
to help reduce the amount of disk space used by Mongo,
but since this option is no longer supported, we'll
have to live with the extra disk space usage.
- Add PR link to History.md
I'm not entirely sure this will work, but the alternative is having to
bump the patch version of every core package, so I'd like to see if this
simplification works first.
