Use latest visit API #71
Conversation
| autoRun: false, | ||
| storeConfigInMeta: false, | ||
| EmberENV: { | ||
| FEATURES: { 'ember-application-visit': true } |
There was a problem hiding this comment.
I initially avoided doing this because feature flags were not being merged. Which meant that if you had a feature flag set in the consuming apps config/environment.js it would completely ignore any features added from an addon's config hook.
This may be fixed now with current ember-cli, but I'd love it if you could confirm. The easiest way to test would be to make a throw away app, set some features in it, run ember fastboot and confirm that the values are merged propertly in the resulting files...
There was a problem hiding this comment.
Hmm, from what I read, the whole thing is deep merged with lodash. I will confirm!
chancancode
force-pushed
the
new-visit-api
branch
from
6415afd to
fbbd195
Compare
| 'initializers/server/*', | ||
| 'instance-initializers/server/*' | ||
| ] | ||
| }); | ||
| } |
There was a problem hiding this comment.
@rwjblue @stefanpenner how does that look? with this I could complete remove the FastBoot global we inject into the sandbox.
By the way, if this works out for us, we might want to move it into the preprocessTree hook so that apps and other addons can use the same pattern
There was a problem hiding this comment.
👍 - This looks great to me!
I don't see a way to completely generalize this, but we can chat about that further in a separate issue...
There was a problem hiding this comment.
Wouldn't it just work if we move this code to preprocessTreeFor? Any initializers in with a browser/... prefix will be stripped for server builds and vice versa. Maybe I am understanding it incorrectly – does preprocessTreeFor not get the fully merged app tree with user code and addon code all merged together?
There was a problem hiding this comment.
@chancancode - Ya, we could come up with something that could work (I misread initially as postprocessTree not preprocessTree). I'm happy to come up with a specific layout/plan to make it a standard thing.
There was a problem hiding this comment.
I'll leave that for another time, probably until someone asks for it :P (if you are reading this, you might just want to PR it 😉)
|
Got the existing tests passing today with some minor fixes! I'll clean it up tomorrow! |
| included: function(app) { | ||
| app.options.autoRun = false; | ||
| app.options.storeConfigInMeta = false; | ||
| }, |
There was a problem hiding this comment.
@rwjblue turns out removing this is not as easy as I thought – contrary to the documentation (see "Uses"), these options can't actually be set through the config hook :( (It makes sense, mutating these build options at a random time during build probably has the same problem as setting autoboot during boot 😉)
@stefanpenner can you c/d? If that's true I can (eventually) send a doc PR
chancancode
force-pushed
the
new-visit-api
branch
4 times, most recently
from
aed139c to
ba48f6d
Compare
Most of the heavy lifting (runtime stuff) has been moved to `ember-fastboot-server`. This addon is currently now only responsbile for building this right app bundle for the fastboot server to consume. The main integration point between the fastboot server and the app bundle is the injected `~fastboot/app-factory` module. This allows the server to create an `Application` instance (not to be confused with an `ApplicationInstance` instance ...:trollface:) without having to discover the app name and the app config. This commit also introduced a convention within the addon: all (instance) initializers within the `browser` directory will be excluded from the fastboot app bundle; conversely, the (instance) initializers contained within the `server` bundle will be removed from the regular build.
chancancode
force-pushed
the
new-visit-api
branch
2 times, most recently
from
3fa9f78 to
e2a8953
Compare
This commit has an implicit cross-dependency on ember-fastboot/ember-cli-fastboot#71. This commit takes advantage of the new visit API in Ember and moves most of the heavy-lifting (runtime stuff) into the server.
We are producing different content for the server vs browser app bundle (e.g. the server one has `autoRun` and `autoboot` disabled), so we need to serve the browser version with `--serve-assets`, otherwise the app won't boot in the browser. The `--assets-path` is somewhat of a quick fix. We should probably run the build process twice and store them in the same location but with a different suffix, like `dummy.fastboot.js` and `index.fastboot.html`.
chancancode
force-pushed
the
new-visit-api
branch
from
5a2df42 to
7589947
Compare
|
Tests are green, fixed all the problems, backfilled the commit messages, did some smoke tests 😬 @tomdale @rwjblue final review? If this looks okay to you, we should probably first merge ember-fastboot/fastboot#2, release 0.1.0, then update the last commit to use the released version before merging. |
| @@ -36,7 +37,10 @@ module.exports = function runServer(callback, options) { | |||
| args.push(commandOptions); | |||
|
|
|||
| return new RSVP.Promise(function(resolve, reject) { | |||
| runCommand.apply(null, args) | |||
| runCommand.call(null, emberCommand, 'build') // build 'dist' | |||
There was a problem hiding this comment.
So this reflects a real-world problem: you need to now run ember build (probably ember build -prod) before you run ember fastboot --serve-assets, because we need to serve the browser builds from dist. (See the commit message for details)
Unfortunately, it is not easy to refactor the set up to produce both builds in a single command (it relies on a global ENV variable, among other things).
So I just added a new assets-path option for now, but we should revisit this in the future.
|
Released 0.1.0 of |
Only access instance.getURL if the instance has booted
…mocha-5.0.0 Update mocha to the latest version 🚀
Update fastboot server for emberjs/ember.js#12394
Require coordination from ember-fastboot/fastboot#2
autoBootFastBootglobalOpen question:
cc @tomdale @stefanpenner