Hopefully, without too much effort, it will be easy to reintegrate much of
the automated BrowserStack testing we (mostly) already had in place! In the
near future, this could be helpful for ensuring we're not over/under-shipping
polyfills to browsers.
Hopefully we can keep this green, though it's not clear to me at the
moment what additional changes I'll need to make to ensure that. For
now, badge!
Some simple messaging changes to the README to account for the fact that Meteor uses not just "pure" JavaScript, but modern JavaScript.
Additionally, link to the React and Angular tutorials, not just Blaze.
Witty as it may be, the contribution guidelines are already listed here (and I've cleaned them up a bit too) and I'm not sure if this terminology is encouraging anyone to contribute their (precious) time.
* 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" (`##`).
This is a wrapup/cleanup on @lucfranken's PR to clarify and clean up the "Slow Start (for developers)" section of the README.
The next step will be to move this to a separate file where much more information can be added, but this incorporates most of the original suggestions and adds some additional formatting.
The README explained how to run Meteor from a checkout.
The example used is the Meteor docs app which is available in the
Meteor repository itself. However it did not mention how you can run
the local Meteor checkout from a local app.
That is the most basic use case, for example to reproduce a bug. That’s
why an example of that is added based on meteor create so we focus on
creating a clean reproduction. That way we can point to it when people
want to debug their own issue.
