My dev environment is Vue + Vuex + Quasar, and I'm not using things like Babel or Webpack directly, but they are used by the build chain. I've recently upgraded the Quasar app to V2, which uses the Babel browserslist to target specific capabilities in the transpiring, and have started to see an error preventing my app from running. If I include IE 11, it works as it used to.
My source code has this Vuex getter defined (I've simplified it slightly to show the issue):
const isValidPage = state => (pageId = state.route.params?.page) => state.event?.pages?.[pageId]
The issue can be shown on the Babel REPL. That transpiled version is pretty much what I see in the browser console:
const isValidPage = (state) => (
pageId = (_state$route$params = state.route.params) == null
? void 0
: _state$route$params.page
) => {
var _state$route$params, _state$event, _state$event$pages;
return (_state$event = state.event) == null
? void 0
: (_state$event$pages = _state$event.pages) == null
? void 0
: _state$event$pages[pageId];
};
It throws (in Firefox 79) a "ReferenceError: assignment to undeclared variable _state$route$params" error. In Chrome 86, it fails at the same point with "ReferenceError: _state$route$params is not defined".
Since I know little about Babel directly, I'm not 100% certain whether this code should execute, whether I need some additional Babel configuration, or whether it's a bug. Pasting the transpiled version into the source code does throw ESLint errors saying that _state$route$params is not defined.
So, it turns out this is a bug in Babel 7. The fix is on it's way.
Related
After Updating from TYPO3 9.5.x LTS and PHP 7.4 to TYPO3 11.5.16 and PHP 8.1 I am getting this error:
get_class_methods(): Argument #1 ($object_or_class) must be an object or a valid class name, string given
I know it's about my Extension (when I disable it the Error disappears), but the further debug Information I are not helping me:
in /html/typo3/typo3_src-11.5.16/typo3/sysext/extbase/Classes/Mvc/ExtbaseRequestParameters.php line 302
// todo: this is nonsense! We can detect a non existing method in
// todo: \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin, if necessary.
// todo: At this point, we want to have a getter for a fixed value.
$actionMethodName = $this->controllerActionName . 'Action';
$classMethods = get_class_methods($controllerObjectName);
if (is_array($classMethods)) {
foreach ($classMethods as $existingMethodName) {
if (strtolower($existingMethodName) === strtolower($actionMethodName)) {
$this->controllerActionName = substr($existingMethodName, 0, -6);
I couldn't find anything searching github, stackoverflow or the web. Anyone else had the same problem or knows where this could come from?
Right after this Post, it came to my Mind to change the PHP Version back to 7.4. With PHP 7.4 I've got a different Error Message ("Class does not exist. Reflection failed.") which leads me to:
https://forge.typo3.org/issues/91239
I made the Mistake to Register Plugin With VendorName. Just in case anyone else does it the same way, I've written this answer and would like to keep this Post.
I'm upgrading scalatags from 0.6.7 to 0.9.3 as part of upgrading scalaJS from 0.6.x to 1.4.0.
I got the following error in some of my tests:
scala.scalajs.js.JavaScriptException: TypeError: $m_Lorg_scalajs_dom_package$(...).document__Lorg_scalajs_dom_raw_HTMLDocument(...).createRange is not a function
Tracing the code, I believe it occurs while executing line 141 of the following scalatags code in `scalatags.JsDom:
I extracted just the createRange call into a separate test and got the same error. "creating range" was printed; "created range" was not and it produced the same exception as above.
createRange() is a native function.
Googling "createRange is not a function" yields a number of similar issues, all seem to be related to testing (but not with ScalaJS). Many of them indicate the "fix" is to monkey-patch document with your own version of createRange. Really?
I initially thought this was an issue with scalatags. Then I thought it's with the scalajs library. Now I'm thinking it's something with Node.js, although Google is not producing any smoking guns.
Suggestions on how to proceed? Try to monkey patch document?
Summary: jsdom appears to be missing the document.createRange function when using Node.js for testing. Others in other languages have similar problems.
The following monkey patch worked for me. After developing this, I noticed that Facade Types has a section on monkey typing.
Also, the library code that tickled this bug (scalatags) actually calls document.createRange().createContextualFragment(v). So I needed to provide something for that as well.
import scala.scalajs.js
import org.scalajs.dom.document
js.Dynamic.global.document.createRange = () ⇒
js.Dynamic.literal(
setStart = () => js.Dynamic.literal(),
setEnd = () => js.Dynamic.literal(),
commonAncestorContainer = js.Dynamic.literal(
nodeName = "BODY",
ownerDocument = document
),
createContextualFragment = (v: String) ⇒ {
val p = document.createElement("p")
p.appendChild(document.createTextNode(v))
}
)
I love testing-library, have used it a lot in a React project, and I'm trying to use it in an Angular project now - but I've always struggled with the enormous error output, including the HTML text of the render. Not only is this not usually helpful (I couldn't find an element, here's the HTML where it isn't); but it gets truncated, often before the interesting line if you're running in debug mode.
I simply added it as a library alongside the standard Angular Karma+Jasmine setup.
I'm sure you could say the components I'm testing are too large if the HTML output causes my console window to spool for ages, but I have a lot of integration tests in Protractor, and they are SO SLOW :(.
I would say the best solution would be to use the configure method and pass a custom function for getElementError which does what you want.
You can read about configuration here: https://testing-library.com/docs/dom-testing-library/api-configuration
An example of this might look like:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
You can then put this in any single test file or use Jest's setupFiles or setupFilesAfterEnv config options to have it run globally.
I am assuming you running jest with rtl in your project.
I personally wouldn't turn it off as it's there to help us, but everyone has a way so if you have your reasons, then fair enough.
1. If you want to disable errors for a specific test, you can mock the console.error.
it('disable error example', () => {
const errorObject = console.error; //store the state of the object
console.error = jest.fn(); // mock the object
// code
//assertion (expect)
console.error = errorObject; // assign it back so you can use it in the next test
});
2. If you want to silence it for all the test, you could use the jest --silent CLI option. Check the docs
The above might even disable the DOM printing that is done by rtl, I am not sure as I haven't tried this, but if you look at the docs I linked, it says
"Prevent tests from printing messages through the console."
Now you almost certainly have everything disabled except the DOM recommendations if the above doesn't work. On that case you might look into react-testing-library's source code and find out what is used for those print statements. Is it a console.log? is it a console.warn? When you got that, just mock it out like option 1 above.
UPDATE
After some digging, I found out that all testing-library DOM printing is built on prettyDOM();
While prettyDOM() can't be disabled you can limit the number of lines to 0, and that would just give you the error message and three dots ... below the message.
Here is an example printout, I messed around with:
TestingLibraryElementError: Unable to find an element with the text: Hello ther. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.
...
All you need to do is to pass in an environment variable before executing your test suite, so for example with an npm script it would look like:
DEBUG_PRINT_LIMIT=0 npm run test
Here is the doc
UPDATE 2:
As per the OP's FR on github this can also be achieved without injecting in a global variable to limit the PrettyDOM line output (in case if it's used elsewhere). The getElementError config option need to be changed:
dom-testing-library/src/config.js
// called when getBy* queries fail. (message, container) => Error
getElementError(message, container) {
const error = new Error(
[message, prettyDOM(container)].filter(Boolean).join('\n\n'),
)
error.name = 'TestingLibraryElementError'
return error
},
The callstack can also be removed
You can change how the message is built by setting the DOM testing library message building function with config. In my Angular project I added this to test.js:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
This was answered here: https://github.com/testing-library/dom-testing-library/issues/773 by https://github.com/wyze.
I am using Backpack for Laravel v4.1.10.
After the upgrade from v.4.0 the filter collapse button in small screens stopped working.
On button click my console error is:
TypeError: can't convert n to string
on the following line of bundle.js (line 9920 expanded):
if (!i && o.toggle && /show|hide/.test(n) && (o.toggle = !1), i || (i = new t(this, o), r.data('bs.collapse', i)), 'string' == typeof n)
Other info: php v7.3.9, Laravel v.7.16.1
Apparently it is not a framework bug as it is not existent in the live demo of backpack.
Any feedback to troubleshoot the issue is very welcome.
I fixed the issue by replacing the bundle.js file with the one provided in the official repository of backpack. Maybe it had not been updated at the version upgrade although I cannot fathom a reason for that.
We are using jquery 1.10.1. we always load 1.10.1 before running intuit.ipp.anywhere.js. The issue we face is that both Jquery 1.6 and 1.10.1(ours) are loaded. despite the fact that there is a checking in intuit.ipp.anywhere.js. after investigating we noticed that the condition window.jQuery.fn.jquery < "1.4.2" is not properly executed. e.g: with JQuery 1.7 we didn't face any issue. It seems that the statement is executed as string compare. Below is the concerned code in intuit.ipp.anywhere.js
if(window.jQuery === undefined || window.jQuery.fn.jquery < "1.4.2") {
// minimum version 1.4.2
var script_tag = document.createElement('script');
script_tag.setAttribute("type","text/javascript");
script_tag.setAttribute("src", "https://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.min.js");
script_tag.onload = function () {
if(window.jQuery) {
intuit.ipp.jQuery = window.jQuery.noConflict(true);
intuit.ipp.anywhere.windowLoad();
}
};
This bug for IE has already been resolved in our previous release.
Please take the latest jquery lib - https://appcenter.intuit.com/Content/IA/intuit.ipp.anywhere.js (if you are loading it locally)
You can also refer-Intuit IPP nuking jQuery in IE