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.
Apply the check for a SyntaxError indicating an incomplete command only
to the ECMAScript translation and parsing of a command and not to the
execution, following the example of Node's defaultEval function.
Fixes#8290.
