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.
* Remove outdated fallback.
* Report used minifier.
This allows packages such as standard-minifier-js to generate statistics per minifier, which is useful to analyze how often the fallback is needed.
* Use official name babel-minify instead of babeli.
* Bump minifier-js patch version to 2.3.3.
To account for the changes in meteor/meteor#9626.
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.
I tried removing babel-runtime from the dev bundle in a recent commit
(since @babel/runtime is what Babel 7 uses), but some tests failed.
Unfortunately Meteor packages like stylus that (1) register compiler
plugins and (2) were last published before Meteor 1.6.1 still need the
older version of the babel-runtime npm package. It's an extra 2MB of dev
bundle size (82MB vs. 80MB), so it's not the end of the world, but I would
like to figure out how to remove it permanently at some point.
cc @abernix @hwillson in case you have any quick thoughts
During the Meteor 1.6.1 beta period, we introduced logic to render a
<script> tag to load the SockJS library in older browsers (#9353), and so
it seemed important to run test-packages both with and without the
<script> tag, using a special query parameter appended to the app URL.
The #9353 changes were ultimately reverted before Meteor 1.6.1 was
released (see 365804218f), and Meteor 1.6.2
will take a very different approach to bundling dependencies like SockJS
for legacy browsers (#9439). As part of this approach, PhantomJS is always
considered a legacy browser, and as such provides valuable feedback on the
behavior of web.browser.legacy bundles. However, since there's nothing to
configure with regard to SockJS anymore, there's no point in running the
test-packages suite twice in PhantomJS.
In order to run these tests in a modern browser environment, we should
probably revisit the idea of running tests in headless Chrome:
https://github.com/meteor/meteor-feature-requests/issues/254
* 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
This could have prevented #9631 from being a problem in the first place,
and feels like the right thing to do, considering the number of cases
we've seen of people accidentally including babel-preset-meteor in their
.babelrc files.
As usual, we have to bump the ecmascript version as well, so that the
compiler plugin will be rebuilt.
