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

Allow Fastboot to work with Lazy Loading Engines #444

Closed
wants to merge 11 commits into from

Conversation

devotox
Copy link

@devotox devotox commented Jul 7, 2017

cc: @trentmwillis

This fixes the merge conflicts from @trentmwillis branch and updates the manifest hook to use lazyLoading.enabled flag

Copy link
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should likely add some new tests. I think we can simply unit test the updateFastBootManifest hooks and the existing build tests will need to be updated for the other changes. I think that should cover everything.

// Separate engines routes from the host if includeRoutesInApplication
// is false
var separateRoutes = this.lazyLoading.includeRoutesInApplication === false;
if (separateRoutes) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the tests are failing partially due to the collisions here. Basically, all the old stuff should still be in the addon we just want to add configEnvironment from the new part to the finalMergeTrees, does that make sense?

Copy link
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, looks like the fix for the browser tests aren't quite the route we should be taking, and the build tests are still failing.

assert.deepEqual(loadEvents[0].split(SEPARATORS), [ '', 'engines-dist', 'ember-blog', 'assets', 'engine-vendor.css' ], 'loaded engine vendor css');
assert.deepEqual(loadEvents[1].split(SEPARATORS), [ '', 'engines-dist', 'ember-blog', 'assets', 'engine-vendor.js' ], 'loaded engine vendor js');
assert.deepEqual(loadEvents[2].split(SEPARATORS), [ '', 'engines-dist', 'ember-blog', 'assets', 'engine.css' ], 'loaded engine css');
assert.deepEqual(loadEvents[3].split(SEPARATORS), [ '', 'engines-dist', 'ember-blog', 'assets', 'engine.js' ], 'loaded engine js');
assert.deepEqual(loadEvents[4].split(SEPARATORS), [ '', 'engines-dist', 'ember-blog', 'config', 'environment.js' ], 'loaded environment js');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, looks like this is loading the new config/environment.js file that we use for Node land. This is sub-optimal as it shouldn't be needed in the browser.

Seems like we have a couple options:

  1. Put the environment config file elsewhere in the output so it doesn't get included in the asset manifest
  2. Add an option to the asset manifest generator to ignore the environment config (would require changes to ember-asset-loader)
  3. Add an additional build step to remove the environment config entry from the generated manifest

@rwjblue do you have any preference here? I'm leaning towards option #2.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What have we decided about this? How do we want to implement it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agreed the second option above seems like the best path forward to me.

(sorry for the delays here)

@trentmwillis
Copy link
Member

@devotox looks like there are still some test failures; let me know if you'd like some help bringing this over the line (I know this code base is kind of crazy)

@devotox
Copy link
Author

devotox commented Sep 1, 2017

@trentmwillis Yes please. The errors seem to be with the fact that there it expects 3 assets but it has 4. I thought the updates with the Ember Asset Loader done by @rwjblue would be enough but I'm guessing there is something more i have to do to exclude the environment config?

@trentmwillis
Copy link
Member

@devotox the changes needed in ember-asset-loader haven't been made yet. I just opened a PR for those: ember-engines/ember-asset-loader#58. Once that's merged we can ignore the config/environment.js files.

@trentmwillis
Copy link
Member

I've released ember-asset-loader@0.4.0 which enables us to ignore the environment config files. Will try integrating it into this PR soon.

@devotox
Copy link
Author

devotox commented Sep 18, 2017 via email

@devotox
Copy link
Author

devotox commented Oct 2, 2017

Anything more on the integration of ember-asset-loader?

@rwjblue
Copy link
Member

rwjblue commented Oct 7, 2017

FWIW emberjs/ember.js#15615 was fixed and released in ember-source@2.15.2.

@trentmwillis trentmwillis mentioned this pull request Oct 7, 2017
3 tasks
@trentmwillis
Copy link
Member

Hate to bounce to yet another PR, but rebasing this was too difficult. I've cleaned up the commits and opened a new PR at #494, which I plan on finishing today (assuming nothing goes horribly wrong). Closing this, but will update when the other PR is merged as I know multiple folks are following this thread.

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 this pull request may close these issues.

None yet

3 participants