DerbyBoutTime / bouttime

'Bout time we got this game started.
Other
32 stars 11 forks source link

Install not working #138

Closed Kateriine closed 7 years ago

Kateriine commented 8 years ago
- Operating System Mac OS X 10.11.6
- Node Version v0.10.36

Might be a bug in node version: install ends with

npm ERR! cb() never called!
npm ERR! not ok code 0
kweerious commented 8 years ago

Could you include more information? Like which command you ran? Did you run the setup.sh first?

Kateriine commented 8 years ago

Oops sorry - I just used npm install -g wftda-bouttime

kweerious commented 8 years ago

Ah thanks, we'll look into that. For now though, we are encouraging local dev installs (see https://github.com/WFTDA/bouttime#development).

Kateriine commented 8 years ago

Ok thanks :)

kweerious commented 8 years ago

@miketheman Looks like CircleCi is passing, but it's using a git checkout and npm install from local. Do you think we should have another build that tests npm installs? I'm wondering how much to rely on NPM really.

miketheman commented 8 years ago

@kweerious I think that eventually we will want npm to be a primary distribution of a completed artifact of this codebase, as it should not contain tests and dev dependencies.

In my mind, the project is still not mature enough to be on npm as an install method, other than reserving the namespace for future releases.

Our docs mention npm install -g wftda-bouttime - we could yank that from the docs until a time at which we are confident in npm as a distribution method.

Is your concern about relying on npm now, or in general for the future?

kweerious commented 8 years ago

@miketheman I'm good with moving the npm install method to the background until we get a production release. My question was more about wanting to test what we use, so we can re-visit the CircleCi using the npm registry later.

miketheman commented 8 years ago

@kweerious that makes more sense now. I see a future where we have an integration test suite, apart from the main codebase, that does the more intense, slow operations against browser types, and that would be the right place to install from NPM directly. Since the majority if the time we'd like to catch regression before release, some thought should go into how that is accomplished.

RawnBear commented 8 years ago

Disclaimer in case you got an email notification about a comment that no longer exists: I posted a comment earlier about an error I was encountering when trying to run the server after using setup.sh to install it, but deleted it because I realised I was probably doing something silly and wanted to try a few more things before asking for help.

Anyway I'm posting now because I've fixed my issue but wanted to provide some feedback on the local development environment instructions:

The problem I encountered was due to not actually compiling the code, which may seem silly but I come from an interpreted language web dev background so I'm not used to this :P

I feel it would be useful to perhaps add a line explaining that gulp watch (or whatever the standard gulp compile command is) must to be run prior to trying to run the server. I misunderstood the line

gulp watch will automatically recompile assets when source files are changed

and thought it was only relevant if I was trying to edit source files on the fly, so I skipped it and went straight to trying to run the server. I see now this was a silly mistake but I tripped up on it and others might too. Just a thought :)