11

I have series of Jasmine tests running against an AngularJs service that uses ECMAScript Internationalization API. They all run successfully when I run them through Chrome. However, when I use PhantomJS to run them through maven, they all fail as it seems PhantomJs does not support Internationalization API yet.

The error message I get for the tests using Intl object is :

1: ReferenceError: Can't find variable: Intl in localizationService.js

And the rest of the tests just fail.

The tests are simple and look like this: 

it('Format date with en-us locale', (function (){
    var date= "06/13/2013"
    expect(service.date(date,'en-us')).toEqual("6/13/2013");
}))

and the methods in service (localizationService.js) are simple wrappers around Intl API:

function getCurrentTimeZone(){
    return Intl.DateTimeFormat().resolved.timeZone
}

function date(dateInput,locale,options){
        // some other stuff
        // ... 
        if (locale) {
            return _date.toLocaleDateString(locale,options);
        } else {
            return _date.toLocaleDateString();
        }
}

My questions are:

1- Is my assumption correct that PhantomJS v1.9.2 does not support ECMAScript internationalization API? Is there anyway to confirm that?

2- How can I approach resolving this issue? I need to run my tests through maven and I will have more tests hitting my localizationService API one way or the other.
Thanks

hippietrail
  • 15,848
  • 18
  • 99
  • 158
Alidad
  • 5,463
  • 1
  • 24
  • 47

2 Answers2

23

Not sure if you're using Karma or not, but here's what I had to do to fix the same issue.

  1. npm install karma-intl-shim --save-dev

    This will also install the polyfill library Intl;

  2. Add 'intl-shim' to the frameworks collection in karma.conf.js:

    ...
frameworks: ['intl-shim'],

  3. Add the locale file you wish to test with in karma.conf.js, for example 'en-US': 

    ...
files: [
      './node_modules/Intl/locale-data/jsonp/en-US.js',
...
kushalbhaktajoshi
  • 4,640
  • 3
  • 22
  • 37
Peter Pompeii
  • 1,415
  • 1
  • 14
  • 16
  • this answer is way better. I suggest accepting this as the correct answer. cheers! – activedecay Dec 13 '16 at 01:31
  • 1
    Worked for me too. In addition to the above steps, also had to add this line: require("karma-intl-shim") to the plugins array in karma.conf.js – vanval Mar 26 '17 at 20:42
  • If you're running tests with --single-run=false, you have to break out of that and restart the process before changes to `karma.conf.js` take effect. Lost about an hour on that one... – João Mendes Jul 11 '17 at 12:24
6

1- Is my assumption correct that PhantomJS v1.9.2 does not support ECMAScript internationalization API? Is there anyway to confirm that?

It looks like PhantomJS is based on WebKit, so it does not support the new ECMAScript internationalization API.

Even for Chrome, the API made it into V8 only recently, it is still in beeding_edge, not in main: See http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/, the i18n files (.cc, .h, .js). This means after the split from WebKit.

Here is the current status for i18n support: http://mihai-nita.net/2013/07/28/javascript-internationalization-api/

2- How can I approach resolving this issue? I need to run my tests through maven and I will have more tests hitting my localizationService API one way or the other.

If I would be the maintainer of PhantomJS I would consider going with the Google branch of WebKit, before it they diverge too much and make it too hard to catch-up. Chrome has more of the market than Safari (not and invitation for flame wars, just a personal opinion without any weight :-)

I am not familiar with PhantomJS, and I don't know what it offers, but if you can separate the JavaScript tests to run on v8 you might try using it for testing from command line. Building beeding_edge was painless, and I did it on Win, Mac OS X, and Linux without any problems.

Mihai Nita
  • 5,547
  • 27
  • 27
  • Mihai, Thank you so much for your answer. I will try V8 approach. – Alidad Oct 09 '13 at 13:46
  • Also if I want to test drive another library while the api is maturing, what would you recommend? I have played with moment, timezonejs, and there are so many others, but what would be a reliable one for a timezone sensitive project? – Alidad Oct 09 '13 at 14:03
  • Most JavaScript frameworks these days have something for i18n, including jQuery, Dojo, Closure. I am not very familiar with them, I would rather bet on the standard or a shim for the standard. Closure has something for TimeZones, but I did not really use it (http://docs.closure-library.googlecode.com/git/class_goog_i18n_TimeZone.html, http://docs.closure-library.googlecode.com/git/namespace_goog_locale_timeZoneDetection.html, and time-zone aware date/time formatting). – Mihai Nita Oct 10 '13 at 06:20