doc: added a quick "Hello World" example in README #850
Conversation
New code added to help completely new users test if their build-from-source is working correctly.
jimmyhsu
changed the title
jimmyhsu
changed the title
| @@ -75,6 +75,11 @@ the binary verification command above. | |||
|
|
|||
| ## Build | |||
|
|
|||
| To quickly test that io.js was built correctly from any of the steps below: | |||
There was a problem hiding this comment.
I don't think it makes sense to explain how to test the build before building. I'd move this to the end of the build instructions.
There was a problem hiding this comment.
I wrestled with this myself, but I was afraid that leaving it at the bottom some people might miss it. I know personally I may have done so myself.
Copying it in each of the different OS instructions seems to be another option, but my thoughts are that it would make the readme too verbose.
Regardless, I'm with you on the logical progression as to where it should be placed. Bottom does make the most sense.
Thoughts or should we stick to putting it at the bottom?
There was a problem hiding this comment.
I'm with @cjihrig. Why test something that isn't built yet? Regarding people not reading a readme -- well, that's not too much to do about.
There was a problem hiding this comment.
@jbergstroem, good point. I've updated the pull request with a new commit that moves it to the bottom.
|
Maybe it is better to use a function that wasn't implemented in the latest nodejs, but differs in iojs. Therefore, we may have a chance to show the new user the difference. |
|
That's a good idea, maybe place that in the resources for new users section? My thoughts were to keep it short and simple just to test if the build was working. |
|
| ### Testing | ||
|
|
||
| To quickly test that io.js was built correctly from any of the steps above: | ||
| ``` |
There was a problem hiding this comment.
minor nit: add a space before the code block
also would be good to have the same code work on Windows and Unixes if you're in a position to check, if not then duplicate the block and for the Windows block use > instead of $
jimmyhsu
changed the title
|
To throw my coals onto the fire, I'd love to see a nodejs.org-like example with an HTTP server rather than a CLI-evaluated line. It doesn't have too much relevance to this PR specifically but it has more value to me than just "Hello". |
|
@brendanashworth I can probably take a tackle at that, but wouldn't that go in a place in the docs and not just the readme? If there's a place I can do that for sure, I'd be glad to do it. On another note, I seem to be having trouble getting ES6 working in my terminal/command line on both OSX and Windows. Is this a known issue, or did I just set it up wrong? |
|
@jimmyhsu I always liked how the nodejs.org example was easy to follow and kind of "in the spotlight", so I'd like to have it in the readme, but its more of a trivial thing. Regarding ES6, I'd say open an issue, if it turns out its an error on your end or a known issue (that I don't know about) we can always close it. |
|
@jimmyhsu looks good! tiny nit: can you rebase the PR against master, squash it to one commit and prefix it with the section you are editing (in this case thank you! |
Did you mean v1.x? Master is months behind. |
|
@bnoordhuis ah thanks yes, meant v1.x |
|
@robertkowalski Sounds good! I'll tackle this later in the week and dig a bit more into why ES6 isn't working quite right. |
|
ping @jimmyhsu |
|
We can use that for testing the build, but I think an actual example should be more thorough. |
PR-URL: #850 Reviewed-By: Stephen Belanger <[email protected]>
|
LGTM. Landed in 54d5437. |
PR-URL: nodejs#850 Reviewed-By: Stephen Belanger <[email protected]>
As per issue #786, added a quick and simple code sample to the build section for new users to test if they built from source correctly.
No source files were modified.