Major Ember upgrade - 1.12 to 3.5 - javascript

In nearest future I will be doing a serious update of the application. I have a little experience with ember.js & have no one who can help me resolving this matter. The app is written in ember 1.12, and there are few dependencies. It has a web version and mobile (iOS+Android) written in cordova - all of them need an upgrade.
What kind of problems should I expect?
How to prepare for them?
How much time should I estimate?
Any help will be very useful- it's first time when I will be doing app upgrade.
I have checked this links, but most of them are for above 2.0 versions.
https://www.emberscreencasts.com/meta_guide_to_upgrading_ember
https://medium.com/ingenious/how-to-upgrade-ember-js-to-3-x-and-live-to-fight-another-day-cfc28c16b726
http://www.ember-cli-diff.org/
https://medium.com/front-end-hacking/everything-you-need-to-know-to-upgrade-your-ember-js-app-including-ember-3-9de5e808dde0
https://medium.com/ember-ish/upgrading-ember-from-1-13-to-2-8-0-f1dbcecc40ca
https://medium.com/front-end-hacking/how-to-use-ember-2-code-in-your-ember-3-app-9ed15c28bad6

Depending on the size of your application and how extensive your test suite is, you'll probably be dedicating a minimum of 4 weeks getting just the web version up to 3.5.
The process will be time consuming and tedious.
1. Upgrade by 1 minor version (1.12->1.13)
2: Run your test suite and fix any issues that come up
3: Manually test the tool by navigating around & fix any issues that come up
4: During the testing, you should have identified a handful of deprecations. Fix those.
5: Repeat steps 1-4
6: After you've upgraded to 2.0.0, you may be able to skip a couple of minor versions at a time, if you aren't using private APIs and your dependencies are small.
Ember maintains their [changelog](
https://github.com/emberjs/ember.js/blob/master/CHANGELOG.md) as well as a page that lists deprecations and their solutions, so you'll want to become buddies with the version you're upgrading to. For each deprecation they mention, check the linked issue history to see what the suggested replacement is. Be proactive - don't wait until the final version to fix a deprecation.
The big/common issues you'll encounter are:
Views are deprecated and removed. You'll need to understand how components work and migrate any existing views to a component.
The select helper gets removed.
If your views & components use targetObject to get the controller, you'll need to make them work without doing it. This means determining what properties & actions need to be passed in and explicitly doing it. Components shouldn't know anything about what called them.
Ember has a solid guide on working with deprecations at https://guides.emberjs.com/release/configuring-ember/handling-deprecations/ that may be of some help.
Keep your changes versioned. You'll break something bad enough that it's easier to just roll back and try again. If you're not using versioning, you're in for a really hard time.
Finally, make sure you clean out your npm directory between versions & wipes - If you don't, you may thing everything is working, but it really isn't.
As Patsy commented - You're probably better off hiring someone who knows ember very well to do this upgrade. If you don't know ember very well, you may be putting fixes in that back you into a corner.

I upgraded a bunch of Ember apps / addons from 1.11 -> 2.18 in advance of the 3.0 release. I don't think there was a single minor version upgrade until the 2.10s that didn't break my app.
I also simultaneously upgraded ember cli with the app. I tried upgrading ember cli to the latest, but I had a bunch of cryptic errors and reached a sort of dead end. What I instead opted for was looking back at the Ember release notes and seeing which version of ember cli was the latest at the time of the Ember release. I would upgrade Ember cli every 4 versions or so, unless if I encountered issues at which point I would immediately upgrade.
The single most important thing is automated tests. I see that you say you have no tests and will just manually test but this is foolish. I had a bunch of code that I needed to upgrade that had no tests. I wrote comprehensive tests over the course of a week since I had two weeks to do the upgrade. These were absolutely vital and some upgrades would break 60-80% of my tests. It would have taken me 2 months without tests probably, but I accomplished it in 2 weeks with the tests, using the first to write the needed extra tests.
Comprehensive tests are best, but far from necessary. At the minimum I would recommend you take the time to mock your API calls and write an acceptance test for each page of your app that serves as a smoke test. The test is as simple as go to the url and check the dom is there. Ember cli page object helps immensely + html5 test-* data classes.
Once you've done that, follow what #Trenton Trama suggested. Upgrade minor version, run tests, fix problems, rinse and repeat until fully upgraded.

Related

Shopware 6: backwards compatiblity of compiled JS in plugin

One of our SW6 plugins comes with fairly basic javascript code. Before shipping it to the SW plugin store, I use the bin/build-frontend.sh script to compile the js assets just as described in the documentation:
https://developer.shopware.com/docs/guides/plugins/plugins/storefront/add-custom-javascript
This has always worked without problems for me. But somewhere in the 6.4.x series, more and more customers reported incompatiblities with their Shopware version. I often have trouble reproducing the error. Most customers report this JS error:
Uncaught TypeError: Cannot read properties of undefined (reading 'call')
My workaround so far has been to install a demo shop with the Shopware version they are using, install my plugin, compile the JS and ship this version to them - with does not seem right at all. Is there any compatibility table or maps which lets me know if a new Shopware Version breaks bw compatiblity when I compile my JS? Or am I missing something?
Any help is very much appreciated.
Maybe this issue is the same like this one: https://github.com/shopware/platform/issues/2420
There was a problem with compiled admin plugins with shopware versions smaller than 6.4.5.0. The compiled code was not compatible with newer shopware versions, but worked with the old ones. When you compile it with a version greater or equal than 6.4.5.0 it will work with all shopware versions.
Maybe this bug also exists for compiled frontend plugins?
Solution for this was to compile it with a Shopware version greater or equal 6.4.5.0 to be compatible with all versions.
No way of knowing without having the actual code.
Generally speaking there shouldn't be breaking changes between minor releases, as long as you're using the provided APIs as intended, e.g. as per the documentation. Most certainly breaking changes are never intended outside of new major releases. The more you move outside of the bounds of the intended implementations however, there will be less of a guarantee for that.
If you can reproduce the error, you can to find which line causes the error by debugging storefront javascript errors. Then you can provide a sample of the corresponding code.

Semver is too difficult or what’s going on?

I noticed that in JavaScript world something changed over time. Previously backend and frontend used semver approach when it comes to version a library or app. Now, in JS world some and I see more and more libraries or frameworks follow the approach to release major version 2 or even more times per year. Let’s take Angular, Ionic for example. Some of my ex or just colleagues also are using the approach.
Why is that? I am asking this as I am a backend developer but I am about to release a JS - powered library and I am a bit confused how to version this.
They release much more frequently major versions precisely to comply with server requirements: they gradually introduce some breaking changes (even if most of the time they are small), therefore release with a new major version.
In the case of Angular, as you notice they plan to release a new major version about every 6 months. The idea is to keep freedom to improve the library without being constantly stuck with full backwards compatibility requirement.

Will my AngularJS 1.x app still work after Angular 2?

I'm near production with my project where i used AngularJS 1.6 and i always ignored Angular2.
I don't plan on refactoring my app to Angular 2, we are already far away and i just want to hand over the app to the client and move on.
My question is will the application continue to work for the next 3 to 5 years ?
It will work until something non-backwards compatible wont be introduced to new browsers which will brake the Angular 1.x framework and stop it from running on it.
How probable is it in the next 3 to 5 years? Not probable at all. Backwards compatibility is one of the top-most priorities, nobody wants to publish a browser which will "brake" a website.
Other question is the maintenance and support of Angular 1.x, that is, will be there a fix if some bug will be found in the framework?
In my opinion 3 to 5 years is a really sure bet, the code base around written using AngularJS 1.x is so huge, and the effort needed to migrate it to Angular 2 is so big, that the support will for sure continue in that time frame.
But beyond that? Well, better slowly start preparing a migration, because in 3-5 years, your software will begin to be considered as "legacy software", and nobody wants that etiquette ;)

What are the differences between using Nightwatch.js vs Protractor

What are the differences? What are the advantages of using one over the other for an Angular project?
Nightwatch.js vs Protractor
If you are working on an AngularJS project, the choice is simple - Protractor:
it is being made specifically for angular apps (though it can be used for non-angular apps also)
supports angular-specific locator strategies (like by.model, by.repeater etc)
waits for angular to start up during the page load (sync)
it is being actively maintained and improved mostly by google developers with a close cooperation with an angular team - this means that protractor follows the angular release cycle and new changes
There are a few more differences that weren't laid out in the top answer.
The big one for me is, as of now, protractor doesn't support phantomJS (http://www.protractortest.org/#/browser-setup#setting-up-phantomjs). I planned on integrating automation in to the CI system, but with protractor I would have to set up a windows VM to run the tests.
Other benefits of nightwatch:
Asserts are done automatically.
Clean console output, you could hand
off to anyone.
Test reports are automatically generated and saved to a /reports directory.
Protractor pros:
The angular-specific locators that protractor supports is very powerful and could help immensely with creating stable tests.
WaitForAngular is also very helpful.
EDIT:
Since the time I wrote this comment and present day our team has happily switched over to using cypress.io. If you are deciding test frameworks I highly recommend checking it out: https://www.cypress.io/

Why Can't I Minify Angular.js?

I'm trying to use Microsoft's Web Optimization bundling toolkit, which works well for everything else.
When I try to ask it to minify AngularJS, though, I get this error message in the resultant Javascript output:
"Ambiguous reference to named function expression"
I'm not even sure where to start with this one . . .
The answer to this question (which should not have been downvoted, in my opinion, because it represents a real issue) is to upgrade from the older Microsoft.Web.Optimization package that uses the "Microsoft.Web.Optimization" namespace and making sure you're using their latest, signified by the "System.Web.Optimization" namespace instead.
In the older Microsoft package, Angular would bomb out when handed to JsMinify. Not so anymore in the latest version.
I hadn't realized at first that I was on an older version of that package because the package name changed - hence my spinning my wheels on it for a while.
The best workaround in my opinion is to preminify the Angular applications using ngmin before minifying with another tool in order to keep dependency injection working.
https://github.com/btford/ngmin
HTH

Categories