Skeletons on master branch vs download link

Best Practices
1

I’m about to launch a new Aurelia app with webpack. The skeletons for download linked by the tutorial are from 2016 and are different from the ones on the master branch. Is there a good reason not to use the the master branch skeletons?

2

You will be better off with the one that CLI creates.
There is a webpack 4 storm at the moment… Seems everyone rushes to upgrade their projects to it.
CLI will set you up for webpack 3. And there is a version of Aurelia-webpack-plugin for v4.

If you have time for fiddling with it… start with 4:
You can grab minimal compatible with 4 configs here:


in demos folder

If you want skeletons - go for master but be warned about not released code…

3

Thanks for your answer.

I went with the cli tool. “au run” asked me if I wanted to use webpack and so I chose yes.

This produced a project that could run, but with broken test frameworks. Jest & Karma both throw errors out of the box.

It also does not seem to generate a command for running the e2e tests even though webpack appears to be configured to run them.

Should I create a separate topic for these issues?

I also tried the default “au new” generated app and everything worked, but it doesn’t support SASS, Jest, or e2e so it’s not helpful for any of my projects.

The master branch skeleton seems to work flawlessly in that I can run the app, run jest, run karma, and run protractor out of the box. I’m not sure what you mean by unreleased code. Do you mean that master is not the current stable release of Aurelia? It would be helpful to know what the dangers of using the master branch skeletons are.

4

Do you mean that master is not the current stable release of Aurelia?

There is no such thing as a current stable release of Aurelia, @guy.jacks. Master branch contains the code that is being prepared for the next release and since the Aurelia framework code is contained in multiple repositories (each of them having a master branch), creating a new Aurelia release requires deep knowledge of mutual compatibility of all these master branches. In most cases it is @EisenbergEffect who acts in the role of the system integrator, and the only safe way to get consistent set of Aurelia framework components is to get them from here, where the latest release is here .

Note that most of Aurelia developers would get a clone of the master branch of any particular framework component for the purpose of testing something, but never to use in the process of building an application to be deployed.

1 Like
5

au jest was fixed in some ways.
You have to manually upgrade pal-nodejs dependency though.
Strangely package.json produced by CLI hardlocks on beta.2.0.0

for e2e I can’t say… there were some issues resolved recently

for released… yes… what’s on master is not considered released. But the skeletons were not released for a long time now…
So there are no guaranties… But if it works for you - great. Does for me as well (-:
No dangers. It’s just a snapshot in time.
I guess nobody expects to to stay with skeleton as it is… It’s a starting point. A skeleton (-:

Experiment your way around.

And share your experiences.

6

Not helping.
Why scare people off with complexities? (-:

1 Like
7

I upgraded aurelia-pal-nodejs. Now it throws the following error. It was already throwing this error before the upgrade when I ran “au karma”. Now it throws it when I run “au jest”.

TypeError: /Users/guyjacks/projects/practice/aurelia-app-two/src/app.js: Cannot read property 'some' of undefined

  at VisitState.onEnter (node_modules/istanbul-lib-instrument/dist/visitor.js:147:65)
  at VisitState.wrappedEntry (node_modules/istanbul-lib-instrument/dist/visitor.js:336:14)
  at NodePath._call (node_modules/babel-traverse/lib/path/context.js:76:18)
  at NodePath.call (node_modules/babel-traverse/lib/path/context.js:48:17)
  at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:105:12)
  at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
  at TraversalContext.visitMultiple (node_modules/babel-traverse/lib/context.js:103:17)
  at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:190:19)
  at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
  at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
8

A-ha… looks like you missing out on polyfils…
CLI creates some jest-settings to bootstrap jest
can you post jest section of package.json?

9

@guy.jacks, have a look at this… might be relevant to your case about karma

10

Here is the vanilla package.json generated by the cli: https://gist.github.com/c68b1f41079fc4be0f7ad4dbb83a0150

11

remove this

 "moduleNameMapper": {
      "aurelia-(.*)": "<rootDir>/node_modules/$1"
    },

and check "/test/jest-pretest.js"
should look like this

import 'aurelia-polyfills';
import {Options} from 'aurelia-loader-nodejs';
import {globalize} from 'aurelia-pal-nodejs';
import * as path from 'path';
Options.relativeToDir = path.join(__dirname, 'unit');
globalize();

where do you have your .spec files?

12

Had a similar issue with the modulenamemapper over at the Store plugin, maybe my fix works for you as well https://github.com/zewa666/aurelia-store/blob/master/package.json