Add file extensions to imports

[FostUK]

In order to support loading Bowser directly in the browser without transpilation this PR :

• Adds .js file extensions to imports.
• Adds ES6 style export to utils and changes related utils imports
• Updates eslint rule for import extensions

Unit tests appear to need no changes as functionality is the same.

Some thoughts
As utils.js is a class collection of static functions it might be better the split them into a set of separate exports. This would mean imports could look like they are in the current master branch:

import { getFirstMatch, getSecondMatch, } from './utils.js';

rather than importing the whole of Utils.

[coveralls]

Pull Request Test Coverage Report for Build 453

• 53 of 53 (100.0%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.01%) to 88.698%

---

Totals
Change from base Build 450:	-0.01%
Covered Lines:	468
Relevant Lines:	483

---

💛 - Coveralls

[lancedikson]

Sorry, but I don't understand, why we need to replace extracted getFirstMatch and getSecondMatch methods to the Utils. I thought all we needed is the ES2015 module export changes in utils.js and the importing part would have a .js added in the end. Do I missing something?

[FostUK]

Totally agree this isn't ideal - it happens is because Utils is currently a class with static methods.
With 'pure' es6 you can't import methods separately from a class (I didn't even realise it was possible with webpack until I saw it here :) )

The ideal option - which I mentioned in the original post above - would be to update the utils.js file into separate exports rather than static methods on a class. I'll update the PR later so you can have a look and see if it's what you want (should be back to looking how it was before except internally utils will export each function rather than export one class)

[lancedikson]

Oh, right. My mistake, sorry. I've forgotten about the class. Actually, having one export produces less code in the end, because after all each module has it's own wrapper when babel transpiles it to ES5. So, no worries then and we can use it like that.