ava: SyntaxError: Unexpected token import

So ava comes with build-in ES2015 support, which works fine for my actual test files. However, when I do

import {newUser, createUser, login} from './helpers/user';

I can't use import and export in the helper file, I then get:

Users/rowe/Code/fv/foxvision-api/test/api/helpers/user.js:1
(function (exports, require, module, __filename, __dirname) { import request from 'supertest';

SyntaxError: Unexpected token import

I have no specific babel configuration set up as for the test files it works out of the box. Can anyone explain to me why the helper dependencies are not transpiled with babel? Using test/**/helpers is even following ava convention.

Thanks, Robin

Solution

So based on thangngoc89's solution, what I did to make it work was:

1. Add a .babelrc with content:

{
  "presets": [
    "es2015",
    "stage-2"
  ],
  "plugins": [
    "espower",
    "transform-runtime"
  ]
}

2. Added to package.json:

"ava": {
  "require": ["babel-register"],
  "babel": "inherit"
}

Solved

AVA only transpile the test files. Not test dependencies so you will need to setup babel in your project (I suppose you did it because you're using ES6 anyway).

Then in AVA's setting, add this :

"ava" {
  ...
  "babel": "inherit"
}

It means that use your project babel setting to transpile the test dependencies. See more information in AVA docs: https://github.com/sindresorhus/ava/blob/master/docs/recipes/babelrc.md

Using rweng, my solution came out a bit simpler.

1. .babelrc

{
  "presets": [
    "es2015"
  ],
  "plugins": [
    "transform-runtime"
  ]
}

2. package.json:

"ava": {
  "require": ["babel-register"],
  "babel": "inherit"
}

Unfortunately standard solution didn't work for my case. Here is my solution which worked for ava + quasar + vue project

.babelrc

{
  "presets": [
    "es2017",
    "@ava/stage-4",
    "stage-3"
  ],
  "plugins": [
    "transform-runtime"
  ]
}

package.json

"ava": {
  "require": [
    "babel-register"
  ],
  "babel": "inherit"
},
"scripts": {
  "ava": "NODE_ENV=test ava",
  "test": "ava",
  "test:watch": "ava --watch --verbose"
}

install modules

yarn add babel-register babel-preset-es2017 @ava/babel-preset-stage-4 babel-plugin-transform-runtime babel-preset-stage-3 --dev

underscore interpolate settings

I'm trying to use handlebars style templating with underscore in backbone (with require.js). I have the following:

_.templateSettings.interpolate = /\{\{(.+?)\}\}/g;

In my templates I have set up a test:

<%= title %> | {{ title }}

I get the following in the browser:

Correct title | {{ title }}

So it looks like the standard underscore template settings are working and the handlebars style ones are getting ignored:

But if I check in the console in chrome I get this (which looks to me like it should be correct)

_.templateSettings
Object {evaluate: /<%([\s\S]+?)%>/g, interpolate: /\{\{(.+?)\}\}/g, escape: /<%-([\s\S]+?)%>/g}

Any ideas why this isn't working correctly?

Amazon S3 + Lambda + DynamoDB Website Hosting

I'm interested in hosting a website for a small business (< 100 users / month) and I wanted to try going 'serverless'. I've read that using Amazon S3, Lambda and DynamoDB is a way to set this up, by hosting the front-end on S3, using Lambda functions to access the back-end, and storing data in DynamoDB. I'll need to run a script on page load to get data to display, save user profiles/allow logins, and acccept payments using Stripe or Braintree.

Is this a good situation to use this setup, or am I better off just using EC2 with a LAMP stack? Which is better in terms of cost?

Solved

It is a perfectly good solution, and will probably cost you nothing at all to host on AWS - literally pennies a month. I host several low traffic sites this way and it works well.

The only caveat would be, since your traffic is so slow, almost every time someone hits a page, if it needs to make any back-end calls, those lambda functions will likely need a 'cold-start', which may introduce a delay and cause the page to load a bit slower than if it had more traffic that tended to keep the lambda cache 'warm'.