My website project has a few JavaScript library dependencies, and I am using the gulp-concat plugin in my gulpfile.js to bundle them as one library instead of including them separately:
gulp.src(['src/js/angular.min.js',
'src/js/angular-route.min.js',
'src/js/angular-sanitize.min.js',
'src/js/domador.min.js',
'src/js/megamark.min.js',
'src/js/woofmark.min.js'])
.pipe(concat('libs.js'))
.pipe(gulp.dest('dist/'));
A problem was introduced once I added the domador, megamark and woofmark libraries.
Although these libraries work perfectly fine if referenced in the HTML separately, bundling them introduces some illegal characters into my libs.js which breaks Chrome:
Uncaught SyntaxError: Unexpected token ILLEGAL
Dev Tools shows me that there are indeed three unexpected characters in-between where megamark.min.js finishes and woofmark.min.js starts:
But! When I look at libs.js in Visual Studio:
There seems to be some kind of 'hidden' characters in the mix which become 'unhidden' to Chrome and kill the script. I don't understand why they are there or why none of things I've tried to remedy it are working...
What I have tried:
Bundle everything except woofmark.min.js and include that separately. Yes, this works, but I want to bundle them all (and I want to understand what is happening)
Re-saved the files in Notepad as UTF-8 encoding. No effect.
Backspaced from half-way through the first keyword in woofmark.min.js, many more times than necessary, then re-typed the necessary characters. No effect.
Similar effort for the last few characters of megamark.min.js. No effect.
Any insight would be greatly appreciated!
Thanks to the information provided by vp_arth in the comments, I found the solution.
It seems that the woofmark.min.js file was encoded as "UTF-8 with signature", which is another way of saying that it has the invisible BOM marker which produced the illegal characters.
When sent separately by IIS it was being converted, but when concatenated in a bundle, the marker was being retained in the middle of the file, creating the illegal token.
To fix, I re-saved the file with a different encoding in Visual Studio:
File ->
Save src/js/woofmark.min.js As... ->
Save with Encoding... -> (button drop-down)
Select "Unicode (UTF-8 without signature) - Codepage 65001" from options.
Then, after re-running the gulp task, the full bundled lib.js works perfectly.
Related
When I try to run a Node.js debugging session from Visual Code, the debugging console returns an error, saying that the bootloader.bundle.js could not be found. However, the bootloader.bundle.js file exists at the expected location, while the debug console specifies the folder incorrectly by substituting a UTF-8 character (letter č) with the replacement character (�). The snippet of the error message can be found below:
Error: Cannot find module 'c:/Users/xxxx xxxx�/AppData/Local/Programs/
Microsoft VS Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js'
Can I somehow fix this in VS Code, perhaps by modifying the launch.json file in some way or some other settings?
Any help is appreciated!
EDIT:
I temporarily fixed the issue by reinstalling VS Code to another folder without that doesn't include diacritical characters. I'd like to to keep this question open, however, in case somebody knows of a way to fix this sort of problem (e.g. by by modifying some configuration files) that does not require either reinstalling or relying on a portable version of the app.
I have just dealt with the same issue. There have been Unicode characters in my folder's path and I got the same error "Cannot find module". Reasons are described in details here.
To fix it I have gone to File - Preferences - Settings and then entered "usePreview" and then I unchecked the option "Use the new in-preview JavaScript debugger for ..." under the section "Debug > JavaScript: Use Preview" and reloaded VS Code. The issue has gone.
I am struggling with getting VS2015 intellisense to work for my requirejs based app.
I followed this article http://blogs.msdn.com/b/visualstudio/archive/2015/04/20/using-requirejs-with-visual-studio.aspx plus some assorted tips from various forums.
I have now gotten so far as to actually make VS realise there are script loader calls in my files.
In the output from the Javascript Language Service the first line indicates that require.config.js has been loaded.
However. As soon as I start typing in one of my module files, the output window is filled with lines like this:
File C:\repository\...\invoices.js contains a script loader file reference
(url = ../services/formvalidator.js, type = text/javascript) that will be
ignored because the upper limit (50) of references that can be added via
script loaders has been reached.
...and intellisense just gives me "Intellisense was unable to determine an accurate completion list for this expression" on all referenced modules.
What do I do now? Surely the whole point of using something like requirejs is to split your code up into separate module files. But if some limit is reached, and no intellisense can be loaded, it seems useless...
Can I change this limit?
Or is something else wrong?
Any suggestions on what to try next?
Cheers!
Kim
I am building an automation suite using Xcode 7 with swift.
My app loads with the following Alert View:
Allow "Light Alarm" to access your location while you use the app?
When I record with UI Testing and click this alert I get the following code:
app.alerts["Allow \U201cLight Alarm\U201c to access your location while you use the app?"]
Note: The quotes has been replaced with \U201c
However, when I try and compile I get the following error:
"Invalid escape sequence in literal"
Anyone know how to get round this?
This seems to be a bug in Xcode when generating code during UI recording.
Swift uses \u{NNNN} escape sequences in string literals, so
app.alerts["Allow \u{201c}Light Alarm\u{201c} ..."]
would be correct, or simply
app.alerts["Allow “Light Alarm“ ..."]
(Actually it should be "Allow “Light Alarm” ..." where the
second quotation mark is U+201D = RIGHT DOUBLE QUOTATION MARK :)
A similar issue for UI recorded code in Objective-C was reported in
Incomplete universal character name in UI Testing.
I do not know a workaround, it seems that the only thing you can do
at present is to fix the code after recording (and sent a bug report
to Apple).
Installing Xcode 7.3 fixed this issue for me
I have met a strange problem with the localized strings. I have only a 'Localizable.strings' in my 'en.lproj' folder and it works fine. all the strings are shown on device. but the next time i compile it and run, it shows only the ID of the strings. even if i change nothing and only click on build&debug. and the next time it works fine again and next time again shown with IDs.
so does anyone knows why this is happening? it's kind of annoying that i always need to build twice.
My SOLUTION is at bottom:
I've been running into the same problem: Alternating runs yield correct, then incorrect translations (only for English though).
Adding "-NSShowNonLocalizedStrings YES" as an argument to the app yielded:
Localizable string "MyKey" not found in strings table "Localizable" of bundle CFBundle
So, I tried loading the key file directly from the bundle as a string and dumping it. Well, the times it did NOT work correctly, it was displaying a bunch of built-in iOS messages. So, I went to the APP file that was built, opened the package contents, and viewed the en.lproj/Localizable.strings file...and voila!!! The file had been filled with Apple iOS key/value pairs. On the next build, it was filled as expected.
Of course, this has nothing to do with the encoding of the files (which should be UTF-16). I have not been able to locate anything with mention of this specific problem.
MY SOLUTION:
I copied the contents of the legitimate english Localizable.strings file FROM THE APP PACKAGE (not from my source) into an XML file (when compiled, the .strings file are converted into XML) and added to my project. I then loaded this file into a dictionary at startup, and if the call to NSLocalizedString returned the key instead of the value, I did a lookup on the dictionary I loaded. In theory, you could do this for all languages, but I was only having the problem with english.
Yes, it's not the answer to the problem, but it's a workaround.
Check if you have more than one Localizable.strings in your project. Merging them into one solved it for me. (Check any external code you use e.g. ShareKit)
I am working on a new version of a firefox extension, but after releasing it, and incrementing the em:version in install.rdf and update.rdf, when I click "Find updates" Firefox reports that "No updates were found." When I run it with debugging on, the output in the console is actually identical to what I see when I don't put the update live.
It starts with RDFItemUpdater:checkForUpdates with all of the parameters, and returns with Addon Update Ended and status: 8.
I verified with McCoy tool that the extension is signed, and has the same Id as the old one, etc. I'm not sure what else to try. Any advice would be appreciated. This is with Firefox 3 (and the extension is marked as compatible with it... that didn't change).
Make sure your update.rdf file is being served with an appropriate Content-Type, i.e. text/rdf, text/xml or application/xml+rdf
If you've only recently changed update.rdf, maybe it's cached. Load it in the browser then Shift-Refresh.
here are some nice tips that helped me: https://developer.mozilla.org/en/Extension_Versioning,_Update_and_Compatibility
but, auto update function will not work if extension is marked "experimental".
I'm having a similar issue, and think it's due to an invalid rdf file. Did you check that yours parsed with this tool? http://www.w3.org/RDF/Validator/
There are lots of things to mess up, one of which is installing an extension from AMO and expecting it to update when you change your update.rdf :)
I was having the same problem. In my update.rdf, I had a wildcard in my minVersion attribute:
minVersion="3.0.*"
Removing the wildcard fixed the status 8:
minVersion="3.0"
The update works now (console shows status 1). This was using Firefox 3.0.18.
My guess is that status 8 means there was a problem understanding the contents of the file (not necessarily an RDF parsing problem). If your minVersion doesn't have a wildcard, maybe there's an invalid character hiding somewhere.