I ran npm update this morning and now my app doesn’t run. This was an update of aurelia-bootstrapper from 2.1.1 to 2.2.0. I also deleted node_modules and ran npm install after the first failure. I also walked it back using git and did only npm update aurelia-bootstrapper to establish that was the responsible change.
By using breakpoints I established main.ts code is being executed but configureRouter in App.ts is not. There are no console errors.
My main.ts includes aurelia.use.standardConfiguration()
Was there a configuration change or something with this update that I’ve missed (didn’t see anything obvious in the release notes at http://aurelia.io/blog/2018/01/22/big-changes-in-the-aurelia-router-150-release).?
what version npm?
do you have package.lock.json?
yes? delete along with node_modules and npm i
also what setup do you use? CLI || Skeleton?
npm -v = 5.7.1
I have package.lock.json
Using cli, currently on 0.32.0 (trying to update to 0.33.1 today failed).
I couldn’t tell you if it was based on a skeleton - it’s been in progress for a year. I have kept the aurelia_project/tasks .ts files up to date as I’ve upgraded the aurelia-cli.
failed how?
You got to be more specific.
You are the first to report it.
Obviously it is about your specific environment.
Can’t help you if we know nothing about it.
OS
node version
CLI version
etc
most probably something wrong with dependencies.
configureRouter should be called if it is there.
can you as well create a new project with cli and see if it runs ok?
bootstrapper 2.2.0 is out for a while.
but other libraries could have been not updated in your setup due to package.lock.json
OK well lol @ the aurelia-cli update - turns out npm’s latest column is in the same color as powershell’s background - only noticed when I pasted here (I thought latest was empty, but can actually see 0.33.1 now).
npm outdated -g --depth=0
Package Current Wanted Latest Location
aurelia-cli 0.32.0 0.32.0 0.33.1
But npm update -g aurelia-cli did nothing.
Yes that worked (without the - on i): npm -g i aurelia-cli
1 Like
Ok (-:
move on to
au new testing-that-it-works
au new project (before upgrade to 0.33.1) using typescript option works - displays “Hello World”.
As it does for 0.33.1 altho via webpack rather than cli.
Am going to update tasks .ts files to those found in 0.33.1 in my main project and upgrade again and see if it helps.
With aurelia-cli 0.33.1 in place:
package.json containing: “aurelia-bootstrapper”: “^2.1.1”, “aurelia-fetch-client”: “^1.2.0”
PS D:\path> rm -r -force .\node_modules
PS D:\path> npm i
PS D:\path> au run
Starts fine.
I have found one area of significant difference.
My devDependencies are quite out of date compared with a new project - most notably aurelia-tools - because ^1.x.y in npm doesn’t update major versions.
Unfortunately even after updating all of those and package.json containing: “aurelia-bootstrapper”: “^2.2.0”, “aurelia-fetch-client”: “^1.3.1”
PS D:\path> rm -r -force .\node_modules
PS D:\path> npm i
PS D:\path> au run
configureRouter is not hit.
To earlier questions: Windows 10, node -v gives v8.9.4, npm -v gives 5.7.1
Ok - put a .catch on main.ts aurelia.start() and got "RangeError: Maximum call stack size exceeded at ViewCompiler._compileElement (http://localhost:9000/resources/vendor-bundle.js:54237:70)
This is the ViewCompiler.prototype._compileElement method and it seems to get stuck on a node: button.dialog-close.
My impression is this is ux-dialog which I am using as use.plugin('aurelia-dialog'), and have two different dialog templates. The element it has got stuck on contains a span with an X, so I’m guessing it’s the close button.
Stepping further the 4th attribute is if.bind = showCloseButton which creates a liftingInstruction. Inside the if(liftingInstruction) condition there is a call to node = liftingInstruction.type.compile(this, resources, node, liftingInstruction, parentNode); which is where the infinite recursion occurs.
I’ve copied my dialog templates into a new project and they’ve seemed fine there. Both project.json files have “aurelia-dialog”: “^1.0.0-rc.2.0.0” as a dependency. So I’m now at a bit of a loss.
I think I’ve made it go away… not really sure how… but I added two steps to my node clearing process and it seems better now:
PS D:\path> rm -r -force .\node_modules
PS D:\path> npm cache clean --force
PS D:\path> rm -force .\package-lock.json
PS D:\path> npm i
The trick seems to have been the package-lock as the cache clean by itself had no effect. I will not claim to even modestly understand npm and why it might behave this way…
Using Internet Explorer by any chance?
Dude… That’s like the first reply I gave you.
I would have found it more helpful in a different communication style.
You asked “do you have package.lock.json?” to which I replied “I have package.lock.json” and then you said “but other libraries could have been not updated in your setup due to package.lock.json”. At no stage was there a suggestion to “try deleting the package.lock.json”, something I haven’t needed to do before.
I also found the following comments unnecessary.
If there is information that would be helpful why not ask for it? I started this thread under the assumption I’d just missed something during an upgrade, not that I was running into packaging/npm problems, so that information didn’t feel necessary at that point.
I appreciate that you’re providing a significant level of responses on this site and that is appreciated. But I would suggest that if the goal is to provide a positive, supportive, and encouraging community, then perhaps we could focus on asking clarifying questions and suggesting possible remedies.
I’ve had similar problems with npm lately, I can’t add a package with first deleting my node_modules folder and sometimes also the package.lock.json.
Tempted to switch to yarn as it’s had time to sort those stupid problems.
Yes. Communication style could be different… I guess…
You could have also payed attention to answers provided.
I pretty much understand that “askers” just need their problem solved.
Here is a very nice blog post by John Skeet about your frustrations:
I’m not sorry I’m a bit disappointed that we both spent more time than was required to solve this one.
Could have ended with my first reply.
P.S.
got to change my signature to House M.D.
@winter_limelight, @Alexander-Taran alright boys, everybody can have that wrong day in the week. Lets keep it professional 
2 Likes