Hi we had a whole suite of cypress tests built around the Robot.ts code from the extensions and after upgrading none of the robot code works anymore. It fails on line 101 of Robot.ts saying that the supplied event is not of type InputEvent which it is. These tests all worked previously in 2.3.14.
Are you using Babel? What kind of module system are you using (AMD, CommonJS, ES modules)? I can’t tell from those screenshots.
webpackOptions.module.rules.unshift({
test: /[/\\].*[/\\].+\.m?js$/,
resolve: {
fullySpecified: false
},
use: {
loader: 'babel-loader',
options: {
plugins: ['@angular/compiler-cli/linker/babel'],
compact: false,
cacheDirectory: true
}
}
});
We suspect that it’s a bug in Babel. Try this library instead:
https://gojs.net/temp/go-debug305a.mjs
Replace the go-debug.mjs file in your node_modules/gojs/release folder.
I assume you’re building/running in development mode and thus are using go-debug*.*
Bit of a complicated implementation, the GoJs piece is within an NPM library that’s built and we have a consuming mock application to run our cypress tests. We use ng-packagr to create the package that gets copied over to our mock’s node_modules folder. All that to say is I’m not sure if it goes into dev mode or prod mode.
Can you change the babel configuration so that it doesn’t minify the GoJS library?
It does not seem to be minified when debugging at the moment, I did change to your provided go-debug file
OK. So you are still having this problem? In the past week or so we’ve been getting a lot of inexplicable exception reports when using v3.0.* that I think are caused by a bug in Babel, although I don’t really understand it. I’m hoping that the v3.0.5 release will include a work-around for that bug, but we still aren’t sure about it.
yes as of right now it’s still an issue, I’m trying to find an alternative loader in my cypress config to see if the babel-loader is the issue
Do you know of a successful angular implementation using cypress automated testing on gojs 3.0.4?
Sorry, I do not know about that. We do intend to create a new sample that uses GoJS v3.0, but we’ve been delayed by various things, such as this problem.
To be clear, what’s failing is a simple instanceof check in the library to ensure that the arg passed in really is an InputEvent. It’s very strange that its even possible for this to fail.
However, if GoJS is somehow being loaded twice, such that Robots.txt is loading one GoJS, and the Diagram creation is loading another GoJS, then its possible that GoJS1.InputEvent is not an instance of GoJS2.InputEvent.
Where GoJS1 and 2 are two separate instances of the library.
I would check carefully that you are only importing GoJS one time, in one way, and that all files in your system are pointing to a single source. Notably, in GoJS 2.3 the Robot.ts file has:
import * as go from '../release/go-module.js';
But in 3.0 it now says:
import * as go from 'gojs';
It is very possible that if you are using the old copied Robot.ts file you still have the old import statement. Or you otherwise have discrepant import statements from where you are making the diagram and where Robot.ts is importing it from. I hope that makes sense.
Robot code was updated to the new extension.
All imports are exactly the same ie.
import * as go from ‘gojs/release/go-debug’; (previously all import * as go from ‘gojs;’)
was able to remove the webpack-preprocessor / babel-loader.
After all that it’s still throwing the exact same error.
What happens if you use
import * as go from ‘gojs/release/go’;
instead?
Also, we’ve released 3.0.5, which fixes a (probably) unrelated Babel bug, but you may want to get it to be sure its not related.
That actually fixes the InputEvent issue somehow.
Well, the non-debug library is just not doing the instanceof check, so it won’t throw the same error.
But I really do think you are somehow accidentally loading two separate instances of GoJS, one for the Robot and one elsewhere, so that you have two go.InputEvent classes defined that are identical but would fail an instanceof check.
I’ve triple checked all the imports and they’re all pointing to the same instance / version of GoJs.
Probably unrelated, but in response to an earlier question: we have updated the gojs-angular-basic sample to use Angular 18. It also works if you upgrade it to use GoJS v3.0.6. But I have not tried using Cypress with it.