Jared Galanis | a/web/dev/blog

Unspecified Bower Components Messing With Heroku Deployment

Sun, 18 Dec 2016 21:45:00 +0000

TLDR; When updating Ember make sure your bower components match what is in your bower.json file before deploying to Heroku

I definitely underestimated how difficult it would be to keep up with these posts. I’m going to try to be more consistent in writing here and as a result I may write more often about smaller issues that I’m experiencing. Apologies in advance if they’re too specific to my builds to be very helpful to folks or overly simplistic.

So this morning I worked through an issue regarding a deployment to Heroku on an Ember/Rails app that I’m building. I recently went through the process of upgrading to Ember and Ember Data to v2.10. If anyone has any issues about how to upgrade your Ember, Ember-CLI and Ember Data versions you should consult this awesome reference on Ember Igniter by Frank Treacy.

When making an upgrade you may be prompted in the terminal about whether you would like to overwrite certain files in your Ember app. This choice can be a bit daunting at first, especially if you know you have made changes to a particular file, and want to keep those changes, but also don’t want to miss out on the changes that might occur in an updated version of the file is seeking the overwrite. I usually make a copy of the file in question, for instance package.json, and allow the overwrite to occur, and then go back in to back into the file afterwards to add in any necessary customizations I may have made.

Normally I get this done right and don’t have many issues. However, on the upgrade path this time around, I did experience a bit of self-inflicted pain. I updated about a week ago and resolved some initial issues and my build was working well locally all week. That was until I tried to push to our Heroku development server.

remote:  !     Precompiling assets failed.
remote:  !
remote:  !     Push rejected, failed to compile Ruby app.
remote:
remote:  !     Push failed
remote: Verifying deploy...
remote:
remote: !	Push rejected to [MY-APP].

Now, I love Heroku, but I also usually cringe when I see an error on deployment, because it isn’t always easy to debug where your error is actually coming from, especially when you’re not very experienced in devOps. Looking upstream in the server log a bit I saw this error which looked pretty suspicious:

remote:        The Broccoli Plugin: [SimpleConcat: Concat: Vendor /assets/vendor.js] failed with:
remote:        Error: ENOENT: no such file or directory, stat [SOME-PATH-TO-A-FILE-IN-MY-CASE-IT-WAS-A-BOWER-COMPONENT]

Note, I’m leaving out the specific names of the components/files that were causing the errors here as they’re not specific to this issue. Anyway, looking at bower.json file I noticed it was looking pretty sparse. I then noticed that there were several bower components in the bower_components directory that were not in the bower.json file. I then also noticed further upstream in the server log that bower uninstall was being run for each of the components that were not referenced in the bower.json file.

remote:        bower uninstall     [NAME-OF-BOWER-COMPONENT]

Finding an old version of the bower.json file in the git repo allowed me to add those references back in easily. There were a few that I did not add back as they were outdated/unused in our project so I just pruned those components and things were back up and running in no time and the push to Heroku worked!

remote:        Asset precompilation completed (143.87s)
remote:        Cleaning assets
remote:        Running: rake assets:clean

Again, sorry if this is too specific or simple for most folks to be helpful, but I’m going to keep writing about this stuff as I know how terrible it can be wasting precious time on these fixes.

Interpreting Rails BigDecimal with Active Model Serializers and Ember

Wed, 26 Oct 2016 21:45:00 +0000

So I’m going to keep this post relatively brief. This is about an attribute type issue I was experiencing while building an ember app with a rails backend using the very helpful Active Model Serializers gem with their JSON API adapter configuration to serve data. In this project we had a Rails model with a column that was a BigDecimal data type. I had some difficulties in dealing with this data type because I was unaware of the way the Active Model Serializers treats Rails BigDecimals, combined with some mistaken assumptions about how Ember handles transformations of data types. Hopefully this can help you avoid the pain I experienced.

TLDR; active model serializers return BigDecimals as a string and if you do not define a transform on your attribute in Ember you may end up working with strings when you expect numbers.

When I first started working with Ember I thought that you had to define a transform for all of your attributes in a model by providing them as an argument to your attr methods. In other words, to borrow an example from the Ember Guides:

import Model from 'ember-data/model';
import attr from 'ember-data/attr';

export default Model.extend({
  name: attr('string'),
  age: attr('number'),
  admin: attr('boolean'),
  birthday: attr('date')
});

This is not the case. You do not have to define a transform for your attr methods. Ember will just pass through the value of the data it’s consuming from the server.

import Model from 'ember-data/model';
import attr from 'ember-data/attr';

export default Model.extend({
  name: attr(),
  age: attr(),
  admin: attr(),
  birthday: attr()
});

Once I realized this I felt liberated from the constraint of having to explicitly define a transform for each attribute in each of my ember models (which are almost always duplicating a Rails-based model). Given the fact that some models in our projects have an ever growing list of attributes this felt especially good. Active Model Serializers seem to do a very good job at handling the treatment of most data types by default. So good in fact that I had never really had a problem with data types in Ember as they relate to our corresponding Rails models. This might cause you to think: Awesome! I’ll just not define a transform for any of my Ember attributes then.

In most situations this works fine. However, I did run into an issue when attempting to use a computed macro in Ember to sum the instances of the values being returned by the Rails server from the column with the BigDecimal data type. Should be easy right? Something like this:

Ember.computed.sum("someBigDecimalAttribute")

BUT … the computed macro was returning a very strange looking number:

99.90889.13

Hrrrmm. Given that the operation of the macro is a relatively simple sum function I could not make sense of what was going on. I spent a good bit of time trying to debug this result making several mistaken assumptions, including that perhaps it had something to do with a failure to resolve promises. Eventually I realized that what I was getting was the sum of two strings:

'99.90' + '889.13' = 99.90889.13

This was occurring because active model serializers was returning the BigDecimal column data as a string and Ember’s computed sum macro was just returning the summation of those strings. The most clear fix that I could think of was to explicitly define the transform on the Ember attribute as a number:

someBigDecimalAttribute: attr("number")

Excellent, that works! The computed macro is now returning the sum of the numbers 989.03 as it should.

Now this is probably obvious from the outset to many who know more about these issues than I do, but I do hope this is helpful to those newly approaching transforms in Ember and saves you a little time.