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
Related
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.
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.
I chose Vue.js for a new project because it seems to run natively in the browser, as opposed to something like React that has to be compiled/transpiled via Node. Is there any reason I couldn't just link to a CDN like this in my production code?
<script src="https://unpkg.com/vue#2.2.1"></script>
A co-worker suggested that may be for development only, and that unpkg is simply transpiling on the fly (which doesn't sound good for performance). But other than that it seems to work fine. I could also link to a more robust CDN such as this one, but just want to make sure I'm not violating some sort of best practice by not using a Node build system (e.g. webpack).
Is there any reason I couldn't just link to a CDN like this in my production code?
No, there is no reason not to use a CDN in production. It's even a preferred way for serving content in production mode, especially with common packages like jQuery, because most of the people would already have loaded and therefore cached this resource.
A co-worker suggested that may be for development only, and that unpkg is simply transpiling on the fly (which doesn't sound good for performance).
This is absolutely not true - that's why it is a CDN! :) It's a matter of choice, but you have to keep in mind that most of the time you should work with specific version of the library that you are using during development. If you just add the latest version of any code, you are vulnerable to all changes pushed to that repository, and so your clients will start receiving updated code, which you haven't tested yet.
Therefore fix to a specific version that you develop with, open a beer and have a good sleep :)
Updated (18.10.2022): Global caching no longer works
Actually, this one's been around for a while, but the answer was never updated. The short story is that caching works per site. Longer version can be found here (thanks to #Baraka's comment).
Either way, using CDN for production deployment is still much preferred!
These maybe help:
<!-- development version -->
<script src="https://unpkg.com/vue"></script>
<!-- production version -->
<script src="https://unpkg.com/vue/dist/vue.min.js"></script>
And it will keep current version of Vue.js automatically.
I'd like to know if there is anything underlying jasmine-jquery like a browser engine or something that it uses to simulate HTML stuff?
Of is it just a self written DOM Model? Is it even a DOM Model?
The reason for that question is that i need to know how reliable tests are written with this fixtures. Can they / should they be used with a whole application loaded into the fixtures for unit testing the application?
How can they be compared to the behaviour of different browsers? So does it behave more like Chrome, Firefox, or even IE6 or is it a custom implementation of the W3C Standards?
Unfortunately i wasn't able to find anything about this. Maybe it's to obvious?
Check out the Karma project. It runs your jasmine tests in real browsers, so you don't have to worry about it.
I'm not sure what engine jasmine uses to power its DOM, but you are better running your front end tests in real browsers.
For node script, use jasmine_node.
Good luck.
Tl;Dr: The fixtures are simply appended into a div with an id of jasmine-fixtures as defined in the jasmine.Fixtures constructor.
You can check for yourself:
fit("See fixtures",function(){
setFixtures("<h1 id='ahoy'>Hello World</h1>");
expect($("#ahoy")).toExist();
alert($("html").html());
});
In your jasmine.jquery.js dependency the code is really clean and easy to follow, check the following methods - Fixtures,addToContainer_,createContainer_
As a sidenote - we currently successfully adopted Jasmine which allows us to follow TDD in a front-end ES5 + jQuery project I am working on. It is a very similar experience to what the test setup of the create-react-app ships with.
I am playing aorund with using LESS along with respond.js to streamline the development of a new site. Both LESS and respond are quite simply neat. However, with LESS in IE I have run into many problems.
For starters in IE8 mode my IE10 reported that id did not understand "map". No problems, I wrote up an Array.prototype map extension. Then it said that it did not understand isArray, once again in IE8 mode. Prototype extensions to the rescue again. Now it comes back saying something along the lines of SyntaxError: Invalid operand to 'in': Object expected
I am not in fact aware of what in might be but in any case I cannot keep adding adhoc prototype extenions on the fly in the hope that things will eventually settle down. Either LESS is unusable with IE or else someone here can point me to all the fixes needed to make it work.
Answer for your question:
First of all, LESS client side compilation is supported only in IE9+.
You could probably fix this using shims and polyfills for ES5, like these.
But please, don't.
What you should probably do (and forget the first part):
However, despite of really good caching mechanisms provided by the LESS compiler (eg. using localStorage to preserve generated code) using it i production isn't considered a good practice.
GruntJS and Bower.io work in the console, but are relatively easy to configure. Basically, you set them up once and forget they've ever existed:)
Livereload provides you with a GUI and it's incredibly easy to use.
I used GruntJS for frontend development with backend developers working with PHP (CakePHP, Zend, Laravel) and it made our lives much, much easier :)
It seems much more reasonable to streamline your frontend development workflow using a task runner like GruntJS or Brunch.io or install Livereload. These tools will monitor the file changes and generate a new CSS file on every save (and also, reload your CSS on the fly).
You can install GrunJS with watch and LESS plugins and keep is very simple this way. You could even use LESS Node.js package installed globally to the job.