Fastboot Issues due to jQuery dependency
We're having an issue with FastBoot since this plugin relies on jQuery to read the revision version.
I've supressed the error with a custom service like this:
import RavenService from 'ember-cli-sentry/services/raven';
import computed from 'ember-computed';
import $ from 'jquery';
export default RavenService.extend({
releaseMetaName: 'sentry:revision',
release: computed('releaseMetaName', {
get: function() {
if (typeof(FastBoot) === 'undefined') {
return $(`meta[name='${this.get('releaseMetaName')}']`).attr('content');
}
}
})
});
But this basically just means that fastboot errors will have no version. Anyone have ideas on a better way to handle this?
The release attribute is calculated so late and injected in index.html because we can't write it to environment.js before (since environment.js gets compiled and included in the hashing operation).
Alternatively you could write a version.json file or so in Fastboot mode, after the build hook, and write the version data in there. Would that help?
One thought I had was that the environment already creates an app version. Is there a reason we couldn't use that as a release version?
That would also give us access to it for raven-node which is what will end up needing to be used for fastboot either way.
Sent from my iPhone
On Jul 18, 2017, at 1:28 PM, Pepijn Schoen [email protected] wrote:
The release attribute is calculated so late and injected in index.html because we can't write it to environment.js before (since environment.js gets compiled and included in the hashing operation). Alternatively you could write a version.json file or so in Fastboot mode, after the build hook, and write the version data in there. Would that help?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
We could totally use that as a release version, I'd be super happy to get rid of the meta hack. @dschmidt see any problems?
Welcoming a PR.