Skip to content
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

Wait for custom event to start building #246

Closed
2 of 6 tasks
viki53 opened this issue Dec 8, 2016 · 5 comments · Fixed by #251
Closed
2 of 6 tasks

Wait for custom event to start building #246

viki53 opened this issue Dec 8, 2016 · 5 comments · Fixed by #251
Assignees

Comments

@viki53
Copy link
Contributor

viki53 commented Dec 8, 2016

What type of issue are you creating?

  • Bug
  • Enhancement
  • Question

What version of this module are you using?

  • 2.0.10 (Stable)
  • 2.1.0-rc.n (2.1 Release Candidate n)
  • Other

Write other if any:

2.1.0-rc.2

Please add a description for your issue:

Hi,

We (@ebarault and myself) are using a mixin to extend our models. this mixin can only start on the booted event, which means that when the SDK builder start, its job isn't done and our models don't have all the proper methods exposed in the generated SDK.

Is there any way to provide a custom event name to the SDK (maybe via an environment variable) to wait a little longer before building?

@jonathan-casarrubias
Copy link
Collaborator

Hi @viki53 thanks for reaching me out.

Hey so, the SDK Builder already awaits for the booted event, I believe it is registered before of the mixing one and it is executed before.... Maybe we need to migrate it to 'started'

please modify the ./node_modules/.bin/lb-sdk

remove the following lines

84 //assertLoopBackVersion();
85 if (app.booting) {
86  app.on('booted', verifyPath);
87 } else {
88  verifyPath();
89 }

change all of them to

app.on('started', verifyPath);

and see if now works

@ebarault
Copy link

Hi @jonathan-casarrubias, I just did, on "started": it launches the server and does not give the hand back to the sdk builder.

@jonathan-casarrubias
Copy link
Collaborator

jonathan-casarrubias commented Dec 12, 2016

I see, what is happening is that within the server.js file it does not start the app when it is exported.

The problem is that we now would need to start the app from the SDK Builder, but that would be done before the boot.... Which won't help..

Maybe for your specific case this could help.

server/server.js

// Bootstrap the application, configure models, datasources and middleware.
// Sub-apps like REST API are mounted via boot scripts.
boot(app, __dirname, function(err) {
  if (err) throw err;

  // start the server if `$ node server.js`
  if (require.main === module) // <----------- Try by removing this condition
    app.start();
});

@ebarault
Copy link

ebarault commented Dec 12, 2016

inded @jonathan-casarrubias : it works. Not totally clean though, as it still starts the server which is confusing for the user. I'd maybe handle this with an env var to explicitly not launch the server when building the sdk.

Do you think it's safe to remove the 'if (require.main === module)' permanently ?


see : despite the server is launched I can still click Y to proceed.

...
WARNING: The targeted SDK Directory is not empty, do you want to erase its content? (Y/n) 

12/12/2016 20:46:01.841 - info: Web server (development) listening at: http://0.0.0.0:3000/api/v1
12/12/2016 20:46:01.842 - info: Swagger API explorer is available at http://0.0.0.0:3000/explorer

(clicked Y)

Loading Framework angular2
Generating "sdk" for the API endpoint "/api/v1"
...

@jonathan-casarrubias
Copy link
Collaborator

jonathan-casarrubias commented Dec 12, 2016

Hey @ebarault I'm glad it worked,

It is safe to permanently remove that condition if you don't need to start the server from outside of loopback -from another module-, in most of the cases you won't do that. If server.js is your main node.js module then there should be no issue.

The server is always booted regardless of what you have done, is just that is now serving the booted objects into the port 3000, which does not make that much of difference. Anyway I think it is complex to ask developers to follow this procedure everytime if they don't have a mixing of this type.

So, I will keep this as an approach for people that requires this, but I will leave the current booting process, since this is a very unusual case.

Cheers
Jon

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

Successfully merging a pull request may close this issue.

3 participants