Skip to content

refactor(gen:endpoint): configurable route url #338

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mvhenderson opened this issue Jul 12, 2014 · 7 comments · Fixed by #350
Closed

refactor(gen:endpoint): configurable route url #338

mvhenderson opened this issue Jul 12, 2014 · 7 comments · Fixed by #350

Comments

@mvhenderson
Copy link

Make the server endpoint base url configurable similar the client directories.

Also remove plurization, make it optional or pluralize correctly (i.e. glass to glasses not glasss) perhaps using underscore.inflection.

If plurization is removed, it should be a one-liner, from:

default: '/api/' + name + 's'

to

default: this.config.get('endpointBaseURL') + name
@JaKXz
Copy link
Collaborator

JaKXz commented Jul 13, 2014

@mvhenderson I keep thinking this is a PR. Would you mind making one instead?

@mvhenderson
Copy link
Author

Sure, will have a PR in a few days.

mvhenderson pushed a commit to mvhenderson/generator-angular-fullstack that referenced this issue Jul 14, 2014
* Configurable route base, defaults to `/api/`. This only affects the
  client URL, the backend code will still be written to `server/api`.

* Configurable pluralization of route, defaults to true.

Closes angular-fullstack#338
@mvhenderson
Copy link
Author

@JaKXz Can you help me figure out why the Travis CI test is failing? npm test worked fine prior to my PR. After seeing the failure, I followed the Travis steps exactly and npm test passed every time I ran it locally. Seems to be affecting PR #351 too.

I suspect this might be an async race condition. In the Travis log, I see this:

Express server listening on 9000, in test mode
  GET /api/things
GET /api/things 200 76ms - 2b
    ✓ should respond with JSON array (94ms)
  User Model
finished populating users
    1) should begin with no users
    ✓ should fail when saving a duplicate user (286ms)
    ✓ should fail when saving without an email 
    ✓ should authenticate user if password is valid (92ms)
    ✓ should not authenticate user if password is invalid (92ms)

However, when I do a default install followed by a grunt test:server I get this output:

Express server listening on 9000, in test mode
  GET /api/things
GET /api/things 200 17ms - 2b
    ✓ should respond with JSON array 
finished populating users

  User Model
    ✓ should begin with no users 
    ✓ should fail when saving a duplicate user 
    ✓ should fail when saving without an email 
    ✓ should authenticate user if password is valid 
    ✓ should not authenticate user if password is invalid 

Notice the finished populating users is in a different location -- could this be getting executed after to the User.remove() call but before the first test in the user.model.spec.js?

Here are the steps I used to try to replicate the Travis error:


$ git clone --depth=50 git://github.com/DaftMonk/generator-angular-fullstack.git DaftMonk/generator-angular-fullstack
$ cd DaftMonk/generator-angular-fullstack/
$ git fetch origin +refs/pull/350/merge:
$ git checkout -qf FETCH_HEAD
$ node --version
v0.10.29

$ npm --version
1.5.0-alpha-1

$ sass --version
Sass 3.3.9 (Maptastic Maple)

$ bower --version
1.3.7

$ grunt --version
grunt-cli v0.1.13

$ cd test/fixtures && npm install && bower install && cd .. && cd ..
$ npm install
$ npm test
...

  14 passing (3m)

@balthazar
Copy link
Contributor

Got the same error few hours ago, I think it's due to some timeout on the server, so little random, get a build error and a passed with the exact same commit.

I manage to resolve the problem by increasing the timeout of the beforeEach in the test-file-creation.js line 37. Maybe that's not the best way to do so and little hacky, but all I found for now.

@mvhenderson
Copy link
Author

@apercu I don't think changing the mocha timeout actually fixed it, just by chance it worked.

Looks like the db operations in server/config/seed.js are async, which is allowing the express app to startup prior to the database seeding to complete during in the Travis test. I need to read the mongoose docs to figure out how to synchronize the seeding to ensure it's complete before the app starts.

@meeDamian
Copy link
Contributor

@mvhenderson nice catch. I was wondering why my purely client side code style fixes raised db errors :). Would love to hear once it gets resolved.

When I npm test it locally it randomly finishes with success or mongoDB error.

@JaKXz
Copy link
Collaborator

JaKXz commented Jul 15, 2014

What @mvhenderson said. Thanks guys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants