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

Maintain correctness when rewriting fastboot-capable apps #125

Merged
merged 2 commits into from
Mar 29, 2018

Conversation

ef4
Copy link
Contributor

@ef4 ef4 commented Nov 3, 2017

Apps that are built with fastboot support contain a fastboot.manifest in their package.json. The manifest includes the names of JS and HTML files. These files may be renamed by broccoli-asset-rev.

Up until now, ember-cli-fastboot has been doing hacks to handle adjusting those references itself. But this requires it to have too much knowledge of broccoli-asset-rev, and it forces ember-cli-fastboot to run after broccoli-asset-rev, which is problematic for use-cases like ef4/prember#2.

This PR reverses that approach by considering fastboot.manifest a standard part of the built ember app that broccoli-asset-rev should know how to update for consistency when renaming files.

This PR includes a flag on the addon itself that we can use to migrate ember-cli-fastboot away from its hacky behavior.

Apps that are built with fastboot support contain a fastboot.manifest in their package.json. The manifest includes the names of JS and HTML files. These files may be renamed by broccoli-asset-rev.

Up until now, ember-cli-fastboot has been doing hacks to handle adjusting those references itself. But this requires it to have too much knowledge of broccoli-asset-rev, and it forces ember-cli-fastboot to run *after* broccoli-asset-rev, which is problematic for use-cases like ef4/prember#2.

This PR reverses that approach by considering fastboot.manifest a standard part of the built ember app that broccoli-asset-rev should know how to update for consistency when renaming files.

This PR includes a flag on the addon itself that we can use to migrate ember-cli-fastboot away from its hacky behavior.
@ef4
Copy link
Contributor Author

ef4 commented Nov 3, 2017

Tests are failing on node 0.12. Current ember-cli supports down to 4. I can also update the CI here to cover a more modern set of nodes if that's acceptable.

@rwjblue
Copy link
Member

rwjblue commented Nov 3, 2017

Hmm. Doesn't this library already support rewriting these files via the extensions option? Note, I haven't tried but I would have assumed that adding json to the extensions list would work without changes here. Am I missing some other issue/caveat?

@ef4
Copy link
Contributor Author

ef4 commented Nov 3, 2017 via email

@rwjblue
Copy link
Member

rwjblue commented Nov 3, 2017

Gotcha, thank you.

We want their local names rewritten but we don’t want prefixing, in just this one place.

👍 I think this is the key bit that I was missing.

json is broader than you really want, although that would maybe be easily fixable with a new option for whole file patterns rather than extensions

I would generally prefer this as I think it would provide a bit more flexibility (and remove some of the fastboot coupling that seems a tad out of place here to me).

@rwjblue
Copy link
Member

rwjblue commented Nov 3, 2017

I'm working through what that option might look like. I was thinking something akin to the way eslint allows overrides, what do you think?

var assetNode = new AssetRev(node, {
  extensions: ['js', 'css', 'png', 'jpg', 'gif'],
  exclude: ['fonts/169929'],
  replaceExtensions: ['html', 'js', 'css'],
  prepend: 'https://subdomain.cloudfront.net/',
  overrides: [
    {
      files: 'fastboot-manifest.json',
      prepend: null
    },
 ]
});

@ef4
Copy link
Contributor Author

ef4 commented Nov 3, 2017

This seems OK but it creates the need for an additional API.

When somebody installs ember-cli-fastboot, I don't want to need to tell them to manually paste some new options into their ember-cli-build.js. We need ember-cli-fastboot to provide the configuration directly to broccoli-asset-rev.

AFAIK there are only hacky ways to do that. Which is a larger topic.

@rwjblue
Copy link
Member

rwjblue commented Nov 3, 2017

I guess I assumed that ember-cli-fastboot would configure the fingerprint options on their behalf.

included() {
  let fingerprintOptions = this.app.options.fingerprint;
  let overrides = fingerprintOptions.overrides = fingerprintOptions.overrides || [];
  overrides.push({
      files: 'fastboot-manifest.json',
      prepend: null
  })
}

🤔

@ef4
Copy link
Contributor Author

ef4 commented Nov 3, 2017

Right, but I consider this hacky for a few reasons.

One is that it's order dependent: we now need to force ember-cli-fastboot's included hook to run before broccoli-asset-rev's (because broccoli-aset-rev is free to copy off its options and start using them right away). While that's not terrible in this particular case (my original problem was that ember-fli-fastboot was running after asset-rev), it's still not ideal. It should be possible for an addon that needs to run after asset-rev to also change settings in asset-rev.

Second is that we're reaching in from far away and mutating state. Which makes things hard to reason about. "Where the heck did this setting come from? I don't know LOL, try grepping."

Third is that we're putting the policy decision of how to merge configs from the app and the addons into the hands of every individual addon. Once you consider that a third addon may want to also alter the fingerprint settings, the combinations get bad.

I realize we only have compromised choices here. Though this discussion is feeding my notes file on how to redesign all addon API.

@ef4
Copy link
Contributor Author

ef4 commented Jan 15, 2018

I would like to argue for merging this PR, based on reiterating my original point:

Fastboot is a first-class feature in Ember. It is not some weird third-party thing. The fact that fastboot-enabled apps include a manifest that makes them runnable by the fastboot library is just something that any addon like this one needs to understand if it wants to be able to do rewriting while maintaining correctness.

If we feel bad about addons needing to understand the manifest, then we should design away the manifest. But right now it is fundamental to the architecture. It is strictly less bad than the opposite alternative, which is attempting to make fastboot understand all possible addons in order to configure them correctly.

@ef4
Copy link
Contributor Author

ef4 commented Feb 12, 2018

This is blocking my ability to land a nice cleanup in ember-cli-fastboot that in turns will unblock fixing a nasty bug in prember that is otherwise unfixable.

@RobbieTheWagner
Copy link

I'm hitting issues with this cycle stuff now as well.

@ef4
Copy link
Contributor Author

ef4 commented Mar 28, 2018

We have now discovered a second use case, which is ember-service-worker also suffers the same issue as prember: broccoli-asset-rev needs to run last, and we can't make it run last unless it's capable of rewriting fastboot apps without breaking them.

@RobbieTheWagner
Copy link

Just to clarify, this is the ember-service-worker and ember-service-worker-prember issue cycle detected: prember <- ember-cli-fastboot <- broccoli-asset-rev <- ember-service-worker <- ember-service-worker-prember <- prember

@rwjblue rwjblue merged commit 81de916 into ember-cli:master Mar 29, 2018
@rwjblue
Copy link
Member

rwjblue commented Mar 29, 2018

Published as 2.7.0

@RobbieTheWagner
Copy link

🎉

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