The most important change in this version is that the Reify compiler is
now just another Babel plugin, so it's possible for other Babel presets
and plugins to run before it.
Fixes#8399.
Fixes#8422.
Fixes https://github.com/meteor/babel/issues/13.
While Babili is much better about handling modern ECMAScript constructs
than its UglifyJS predecessor, it may still be possible for an error to
occur during minification.
To account for that unlikely situation, and to preserve the code already
written to assist in that situation, this implements an error re-throw
in a similar fashion to that of 1a380f5532.
The `ecmascript` package, when `use`'d in a compiler, is included in the
build of the package, thus increasing the size. For this simple package
I'm not sure the benefits will actually be worth it.
This points the `blaze` submodule in the Meteor repository to:
https://github.com/meteor/blaze/tree/minifier-babili
This `minifier-babili` branch excludes new HTML5 tests which are failing
on PhantomJS, namely, the HTML5 tests which were added by:
04db0d40ce
While I believe the `VIDEO` tests are the most problematic, there is
nothing about the tests themselves which are lacking. In fact, the
tests do run successfully on the Blaze repository and the changes have
actually been released for a number of months on Blaze itself, however
the submodule in Meteor hasn't been updated until now.
Meteor only uses `blaze` for generating templates in the
`boilerplate-generator` package and doesn't utilize the HTML5 in
question, nor is Meteor responsible for Blaze testing anymore.
Ultimately, our `test-in-console` needs to be updated to use
another option aside from PhantomJS, but I don't believe that should
hold up releasing this Babili minifier which solves a number of issues
in meteor/meteor#8378.
Many aspects regarding contribution of code can be better explained in the new `Development.md` so provide links to those relevant parts.
Follows up on https://github.com/meteor/meteor/pull/8267
We only need version constraints on core packages in some cases. For
example, when referring to "core" package wrappers (like `npm-mongo`)
which uses an API outside the Meteor build system.
* Blank slate Development.md
* Move "Running Tests" to Development.md
* Move "Running from a Git checkout" to Development.md
* Add information on running specific tests.
* Move the "run against local" disclaimer up to the first paragraph.
* Change header level to be the same as others.
* Remove superfluous section about running specific tests.
* Slight text adjustments
* Add information about continuous integration tests.
* Call the tool tests what they are: self-tests
* Add information about listing tests.
* "argument" => "option", since that's what it is.
* Move "more details" up higher in the text.
* Add test headings.
* How to: Run or exclude specific tests from the self-test tool.
* Add a link to Contributing.md from README.md
* Additional documentation = README.md files
* Add information about running your own CircleCI.
* Add section on code style.
* Add section on commit messages.
While the title is obvious, I guess I should add a commit description
here for the sake of fully explaining the importance of a good commit
message! This commit, along with the ones before it should help make it
very clear how to contribute to Meteor!
* Update core contributor list.
In addition to adding myself, this adds Hugh Willson (@hwillson) and removes past contributors not currently active.
* Add information on finding work for those who want to contribute.
* Add link to documentation repo.
* Refer to the "Finding work" section from "Submitting pull requests".
* Refer to Roadmap.md from "Tracking project work".
* Hoist "Finding work" up to a more helpful location.
* Add note about files which are ignored by auto-linting.
* Clean up grammar on commit message "Fixes" notation bullet-point.
* Add link to guide.
* Suggest the use an alias for frequent contribution.
Per PR suggestions, add a suggestion to make an alias for more frequent use. Also, due to difficulty of formatting aforementioned change, move unrelated Note (which didn't belong there) to a more prominent section called "Notes when running from a checkout"
* Add information about the "Dev Bundle".
This moves the dev bundle step out of the "Running from checkout", simplifying those steps, but breaks things down much more in its own, new, section.
* Changes as suggested.
Thanks to @klaussner and @hwillson for these suggestions! I also changed some other trademark-y things. 😉
* Add a "more reading" section per discussion.
cc @hwillson
* Add a header to `Development.md` explaining its purpose.
Great suggestion, @benjamn. Thanks.
* Fix header type of "Notes when running from a checkout".
This was inadvertently set as a "H1" (`#`) but should have been nested within the "Running from a Git checkout" section as an "H2" (`##`).
We now check `package.json` in order to help make an educated decision
as to whether or not a package has binary dependencies which need to be
rebuilt. In some cases, such as the `npmconf` npm which is included
as a dependency of `flow-router, the `package.json` is invalid (i.e.
empty), and we should silently permit this.
Fixesmeteor/meteor#8427
Because as @hwillson rightfully points out:
> that's what we're really exposing and `connect` themselves refer to the container that holds the defined middleware (the result of calling the `connect()` function) as a connect "app"."
As per the comment on line 653, this appears to be the best (only?) way to let users do things like set up a custom error page to catch app-rendering-time exceptions.
This is a developer experience (DX) change.
In production, the `METEOR_SETTINGS` environment variable is used to
pass parameters which will be available in the `Meteor.settings` within
the app. However, `METEOR_SETTINGS` is ignored when using the
`meteor-tool` itself as in development, environment variables are
often less desirable. Additionally, there would be no reactivity when
changing settings was necessary, instead requiring that the `meteor`
tool be restarted entirely.
On more than one occasion, developers have been confused as to why the
`METEOR_SETTINGS` are not respected in development. To make it more
clear when this is attempted (and clarify that they will _not_ be used),
provide the a clear warning before ignoring the `METEOR_SETTINGS`
variable.
Aims to avoid meteor/meteor#8455.
