ember-cli / rfcs

Archive of RFCs for changes to ember-cli (for current RFC repo see https://github.com/emberjs/rfcs)
45 stars 54 forks source link

Refactor EmberCLI to run Build Pipeline, Express Server & Testem Server in separate processes & corresponding addon API #4

Closed taras closed 5 years ago

taras commented 9 years ago

RFC

taras commented 9 years ago

@bcardarella @stefanpenner @abuiles @rwjblue What do you guys think?

stefanpenner commented 9 years ago

this also replaces the current hacky reloading stuff we do.

stefanpenner commented 9 years ago

I would love to visit this again post 1.0, It will need some investigation but still am +1

stefanpenner commented 8 years ago

I like where this is going, but this needs more fleshing out, specifically.

  1. error handling (processes fail, either parent or child etc), we need to be sure they crash correctly, and cleanup occurs correctly.
  2. what does the process tree look like?
  3. ability to reload reprocesses etc.
nathanhammond commented 8 years ago

@taras et al.:

The ability to spawn and manage processes as well as pipe information from one process into the next is something that we want inside of ember-cli. This is a required component to be able to build Ember applications and have them play nicely with things like NW.js, Electron, Cordova, and more, many of which have their own specific tools which we need to integrate with gracefully.

For the creating processes themselves, we would like for them to be achievable as an ember-cli addon, as well as being addressable from other "peerDependency" addons. We'd then delegate back to the ember invocation at specific points in the lifecycle in order to allow ember-cli to manage the processes.

So, with that, we do want this feature, but we'd like this RFC updated to address specific implementation details for arbitrary process counts, process relationships, bidirectional communication, references to the process itself, failure recovery, and things we've not yet discovered since we haven't tried to complete this design work.

This is part of our "core + extensibility" efforts.

stefanpenner commented 8 years ago

I like where this is going, but this needs more fleshing out, specifically.

error handling (processes fail, either parent or child etc), we need to be sure they crash correctly, and cleanup occurs correctly. what does the process tree look like? ability to reload reprocesses etc.

^^ should be addressed for this RFC to help us explore the solution here.

Turbo87 commented 5 years ago

closing due to inactivity 😢