How to handle running in Node

[trentmwillis]

When running an Ember application in Node (such as through FastBoot), the asset-manifest module blows up since it can't read from the DOM (which doesn't exist).

There are patterns to handle this, but it raises the overarching issue of how should lazy assets be handled within a non-browser environment.

Open questions:

• Should the Asset Manifest be present in Node? Or should it just be an empty config?
  • If the manifest is present, what should the loader functions do?
  • If the manifest is not present, what happens when a code path is hit that expects to load something?

My current thinking is:

In a Node process, all assets should be loaded upfront (need build targets in order to do this easily), but the manifest should still be present so that if a code path expects to load a bundle (or similar) it doesn't kill the app. This would mean that the loader functions should all return immediately resolving Promises (Promise.resolve()).

@nathanhammond @dgeb @rwjblue would greatly appreciate hearing your thoughts on this

Tasks:

• Pre-load assets in non-browser environments (should be handle by whatever booted the application)
• Enable asset-manifest to be present in non-browser environments [PR]
• Return resolved Promises from loaders in non-browser environments [PR]

[kratiahuja]

+1 to loading everything upfront in sandbox for server side. It makes fastboot independent of app loading strategy and will probably not have a negative impact on server side rendering.

[trentmwillis]

I've updated my original comment with what I believe are the tasks needed to make this work properly.

[trentmwillis]

The pre-loading of assets poses an interesting problem, since this addon doesn't actually have any control over the build. Should this addon just assume that everything is pre-loaded? But leave the actual act of pre-loading up to the environment? I tend to think, yes.

[nathanhammond]

actual act of pre-loading up to the environment.

I tend to agree that the environment should invoke loadBundles/whatever that is prior to booting since that is very environment specific.

[trentmwillis]

the environment should invoke loadBundles/whatever that is prior to booting

Won't want to do loadBundles, the environment should just load the scripts into it's VM. Like what currently happens in FastBoot for vendor.js and app.js, see here for reference.

[trentmwillis]

A path forward has been established and necessary changes have been made here. Will release version 0.2.0 soon with those changes.

[joebartels]

Could you share how exactly to configure this addon with fastboot and where the node-asset-manifest.js file should be located and from where it's consumed?
(apart from doing noManifest: true in the ember-cli-build.js file)

[trentmwillis]

As far as I am aware, there is currently no way to configure this addon with Fastboot. The pieces are in place from this side, but from what I know there is no prescribed way to load additional files into the Fastboot sandbox which is what needs to be done for this to work.