Error Quarto require invalid module (bertin.js) - javascript

I have developed the library bertinjs which allows to make svg interative maps. In Observable, require("bertin") works. In Quarto, require("bertin") does not work. The following error is returned: OJS Error. RequireError$1: invalid module. See the issue on Github (see). It's weird. Any help is welcome.

(Quarto dev here) I recently fixed a bug that would cause that behavior you're seeing. Can you try a release later than 0.9.430? Thanks!
Edit: I see now that bertinjs uses modern JS syntax, which the stable versions of the RStudio IDE don't yet support. Your example works on the latest Electron daily builds, the right-most column on the linked page.

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.

maps.googleapis.com incompatible with date.js

Recently encountered a problem with a long standing asp.net c# program.
In my default.aspx amongst other things we have...
<script src="https://maps.googleapis.com/maps/api/js?key=...&libraries=geometry"></script>
<script src="/js/date.js" type="text/javascript"></script>
date.js is a utility library from http://www.datejs.com/
Just recently (last 6 weeks) our map is failing to draw anything, after a bit of investigation it seems that there's a toString() in one of the maps library files that tries to use the toString() from the date.js file and fails miserably.
Uncaught TypeError: format.replace is not a function
at Date.toString (date.js:40)
at iq (common.js:65)
at Object._.Bq (common.js:75)
at map.js:83
For the moment I can specify the version of google maps, 3.40 works fine, anything later doesn't.
Does anyone have a solution to this or has anyone seen this problem? Granted date.js is very old library now but I wondered if there's anything simply I can do.
Google suggests pointing to a more recent version of date.js https://github.com/datejs/Datejs/issues/88
I haven't checked it yet but confirmed it is failing with an old date.js
I am also getting the same error in version 3.41,
but after changing it to version 3.40, It works!
Ran into this same issue in a Rails app, updating data.js to a more recent version fixed it. There's a more recent fork that's available here that fixed the issue for me: https://github.com/abritinthebay/datejs

Polymer webcomponents cross-browser compatibility

I'm having frequent problems when using Google Polymer with non-Chrome browsers (Firefox/IE). Using Polymer on its own (such as viewing Polymer Element demo pages) does not seem to cause any issues. However, issues arise when using webcomponents.js is included on an existing web-application with many included GUI and utility packages (jQueryUI,
The issue seems to be related to webcomponents.js specifically. If no HTML imports are used and only webcomponents.js is imported, it throws the same error in both Firefox and IE:
webcomponents.js:2114 - SyntaxError: An invalid or illegal string was specified
webcomponents.js:113 - Error: Assertion failed
The specific line of webcomponents.js simply reads:
list = originalDocumentQuerySelectorAll.call(target, selector);
- which seems to have no immediately obvious syntax error.
Due to this error, other GUI elements on the page now exhibit erroneous behavior. There is no other useful console output provided when this happens, and no exceptions thrown by other JS packages. None of this behavior is shown when using Chrome.
I had the same error. I solved it, loading webcomponents.js before jquery.js.
I've tested with the last version of webcomponents.js in the last version of Firefox, simply loading it (no other import used) and it seems to work...
Test here
Plunker here
Did you tried with the last version of webcomponents.js or it was an old one? How about the version of Firefox?
Couldn't test on IE, I'm on linux, sorry.
I had the same problem when loading jQuery(v1.10.2) and polymer(webcomponents.js).
Fixed it using jQuery v2.1.4.
I was able to resolve the issue by removing $(document).ready from the script.
Not quite sure if this is still relevant but I bumped into this recently while running the unit tests using web-component-tester for a Polymer 1.11 based application. This issue start appearing on chrome v81 and was working fine before.
So, in each of the spec file we have an import for webcomponents.min.js which I replaced with webcomponents-lite.min.js and that worked for me.

Script error with loading jQuery in IWebBrowser2

The following error shows up when I load a page that uses jQuery in my iWebView.
I checked if the JS files have any errors, but they all seem fine.
Any clues anyone?
Vasa, the latest 1.x version is 1.11.1:
https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js
You may want to try pointing to that to see if the upgrade has fixed your script error. Also, using the non-minified version for development may give you more detail to line and character.

How can I get Screw.Unit to Run on Internet Explorer

Using the repo found here:
http://github.com/nkallen/screw-unit
and this commit:
cc41f3cf373d804b11519704faf1971370f43760
I get this screen when viewing the package's "EXAMPLE.html" file:
Basically all of the text showing how many tests were run and the describe/it clauses, and the test results are missing.
The same revision works fine on Safari and Firefox.
I found this report that seems related, but no follow-up:
http://groups.google.com/group/screw-unit/browse_thread/thread/f0e82f5d68acbf21
Any ideas?
Edit: I found that upgrading jquery from version 1.2.6 (included with package) to 1.4.2 results in a screen in which green/red tests show up. Unfortunately, the top header showing the number of total tests and failing tests does not show up.
For those who may be hitting the same problem, I've found that the Pivotal branch of Screw.Unit seems to give exactly the same output for EXAMPLE.html in both IE7 and FF. There are others to choose from as well.
Save yourself the trouble and use Jasmine. It runs on all browsers, offers custom matchers, works on all browsers, is offered by Pivotal Labs, and is wicked fast. Syntax is very close to Screw.Unit, so porting is not conceptually difficult.

Categories