I am building a Nuxt3 app and trying to integrate Cypress. As I'm aware Nuxt3 uses Vite instead and not babel, I was trying to instrument the project code using vite-plugin-istanbul npm package.
Here's my nuxt.config.ts after installing vite-plugin-istanbul package:
vite: {
vue: {
template: {
transformAssetUrls: true
}
},
plugins: [
istanbul({
exclude: ['node_modules', 'test/', 'coverage/'],
extension: [ '.js', '.ts', '.vue' ],
cypress: true
}),
]
},
When I'm trying to run the server using npm run dev and visit the localhost URL, the following error is thrown at terminal:
[nuxt] [request error] [unhandled] [500] window is not defined
at cov_1291n0zka8 (./.nuxt/dist/server/server.mjs:3623:191)
at $id_Sv05hbOoTf (./.nuxt/dist/server/server.mjs:3624:75)
at async __instantiateModule__ (./.nuxt/dist/server/server.mjs:40418:3)
It seems the plugin is instrumenting the server-side rendered code and window object isn't defined there. I need to have SSR enabled in my app and I'm not sure of how to handle this error.
This issue has been resolved by the plugin authors.
TLDR version
Just update the vite-plugin-istanbul package to the latest version and the issue should get resolved.
Long version
There are two parts to this error:
The package was originally configured to transform all the files. The plugin authors have now added a condition that checks whether the SSR has been enabled or not. This is done via options.ssr property within the transform function. Please upgrade to the latest version of vite-plugin-istanbul. The plugin no longer instruments the SSR files, hence the window object error no longer exists in there. Follow this thread if you need more details.
After getting this error resolved, I was still facing another issue where the code instrumentation was impacting the proper app compilation and throwing a hydration mismatch error. The plugin authors came to the rescue again and fixed this error. Please upgrade to the latest version of vite-plugin-istanbul. Follow this GitHub thread if you need more details.
The package authors are really awesome and helpful. It's great to see such people in the open source community!
Related
I'm trying to use the aws-amplify node package in my mini-programs project. However, when I try to run import Amplify, {API} from 'aws-amplify, I get the following error:
Can't reexport the named export 'package_name' from non EcmaScript module (only default export is available)
I have tried to depreciate the npm package aws-amplify to a older version as Mini-Programs run on the previous version of NodeJS.
After doing some research on the issue, I found a solution that recommended to add the '.mjs' extension to the webpack.js config file. However, being sub-app on the VodaPay environment - I don't have access to the webpack.js file.
resolve: {
extensions: ['.mjs', '.js', '.jsx', '.css', '.scss'],
modules: [
path.resolve(__dirname, 'src'),
'node_modules',
],
},
Some npm packages are not compatible with mini programs due to them not having access to the DOM.
The AWS amplify package isn't compatible because of this. It makes use of the fetch() JavaScript function which isn't supported in the mini programs.
By just importing the package into an empty mini program I get this error in the console:
TypeError: Cannot read property 'fetch' of undefined
I am unable to run e2e tests with protractor 7 with the following configuration
...
directConnect: true,
capabilities: {
browserName: 'firefox'
}
...
on my MacOS Catalina. I noticed the
webdriver-manager update
command from the project's package.json downloads the geckodriver-v0.29.1.
As mentioned in the title the logs do not go beyond Using FirefoxDriver directly... when I run the tests. How can I check logs in more details (is there a verbose option in protractor?), and how can I fix the issue ?
With Splaktars answer I was able to get Firefox to launch using the typical directConnect: true setting.
I had to download the geckodriver-v0.29.1-macos.tar.gz package from the Github Releases and extract the binary. Then I replaced the geckodriver-v0.29.1 binary previously downloaded through webdriver-manager with that copy from the package.
After that I launched my tests to make sure everything was still partially working and finally saw the MacOS security popup. I ran the command to remove the quarantine flag:
xattr -r -d com.apple.quarantine /path/to/geckodriver-v0.29.1
Relaunched the tests and finally Firefox popped up...
Thanks again to Splaktar, just made an account so I can't comment or upvote for help
It looks like there is a known issue in the v0.29.1 release notes:
https://github.com/mozilla/geckodriver/releases/tag/v0.29.1
Those point to some GeckoDriver macOS Notarization docs:
https://firefox-source-docs.mozilla.org/testing/geckodriver/Notarization.html
However that page say
Arbitrary software downloaded through other means, such as curl(1) is not affected by this change.
I don't get any security pop ups or warnings, just the hang that you see.
Running
xattr -r -d com.apple.quarantine /Users/splaktar/Git/app/node_modules/protractor/node_modules/webdriver-manager/selenium/geckodriver-v0.29.1
Doesn't help.
In https://github.com/angular/protractor/issues/4253, there are a lot of old issues mentioned with Firefox and directConnect support. I tried using directConnect: false with a suggestion from that issue:
config.capabilities = {
'browserName': 'firefox',
'marionette': true,
'elementScrollBehavior': 1
};
config.directConnect = false;
config.seleniumAddress = 'http://localhost:4444';
config.localSeleniumStandaloneOpts = {
jvmArgs: ['-Dwebdriver.gecko.driver=node_modules/protractor/node_modules/webdriver-manager/selenium/geckodriver-v0.29.1']
};
I ran webdriver-manager start and then ran my tests, but that failed quickly with an error page's HTML in the console and From: Task: WebDriver.createSession() Process exited with error code 199.
I also tried setting
config.firefoxPath = '/usr/local/bin/firefox-bin';
after creating a symbolic link there to /Applications/Firefox.app/Contents/MacOS/firefox-bin. But that didn't help at all. Firefox never gets started. I tried with Firefox Developer Edition as well.
Still investigating...
I am using yarn 2 and react with webpack.
In my package is "typescript": ... defined. Once I start yarn start I am getting an error:
yarn workspace test start
When you use this plugin you must install `typescript`.
What is wrong? How should I fix it? Or debug it?
I've faced the similar issue when I was upgrading webpack from 4 to 5.
The problem was the version of react-dev-utils
Upgrading react-dev-utils from v10 to v12 made the issue disappear.
devDependencies {
...
"react-dev-utils": "^12.0.1",
...
}
You can be checked the value of your plugins config about ForkTsCheckerWebpackPlugin which the param key named tsconfig.
Error Message
Check [key, value] about ForkTsCheckerWebpackPlugin.
Find it in your node_modules, and set debug point, run the debugger.
You need to take a look at your webpack.config.js where ForkTsCheckerWebpackPlugin is initialized. ForkTsCheckerWebpackPlugin needs to be able to find the tsconfig file.
new ForkTsCheckerWebpackPlugin({
typescript: resolve.sync('typescript', {
basedir: paths.appNodeModules,
tsconfig: paths.appTsConfig,
})
}),
In my case I'm defining paths.appNodeModules and paths.appsTsConfig in a file called paths.js.
module.exports = {
appTsConfig: resolveApp('tsconfig.json'),
appNodeModules: resolveApp('node_modules'),
};
I'm wondering how to define dependencies (other non node-windows nor node.js windows services).
In the code of winsw (HERE) I've found out it should be possible.
For me it seems to be a "issue" in node-windows as winsw can do it by adding following code to the service .xml file:
<depend>Eventlog</depend>
I think I got it, it's implemented but not documented (at least I didn't found it):
https://github.com/coreybutler/node-windows/blob/master/lib/winsw.js#L25
https://github.com/coreybutler/node-windows/blob/master/lib/winsw.js#L110
That brought me to the following (example) code:
var svc = new Service({
//...,
dependencies: [
'EventLog',
'W32Time'
]
});
I have a React application with ApolloClient with Apollo-Link-Schema. The application works fine locally but in our staging environment (using GOCD), we get the following error:
Uncaught Error: Cannot use e "__Schema" from another module or realm.
Ensure that there is only one instance of "graphql" in the node_modules
directory. If different versions of "graphql" are the dependencies of other
relied on modules, use "resolutions" to ensure only one version is installed.
https://yarnpkg.com/en/docs/selective-version-resolutions
Duplicate "graphql" modules cannot be used at the same time since different
versions may have different capabilities and behavior. The data from one
version used in the function from another could produce confusing and
spurious results.
at t.a (instanceOf.mjs:21)
at C (definition.mjs:37)
at _ (definition.mjs:22)
at X (definition.mjs:284)
at J (definition.mjs:287)
at new Y (definition.mjs:252)
at Y (definition.mjs:254)
at Object.<anonymous> (introspection.mjs:459)
at u (NominationsApprovals.module.js:80)
at Object.<anonymous> (validate.mjs:1)
Dependencies are installed with yarn, I've added the resolutions field to the package.json.
"resolutions": {
"graphql": "^14.5.8"
},
I've checked the yarn.lock and can only find one reference for the graphql package.
npm ls graphql does not display any duplicates.
I thought maybe its a build issue with webpack - I have a different build script for staging, but running that locally I am still able to get the react application to run with that bundle.
Can anyone suggest anything else to help me fix this?
I managed to find the cause of the issue, if this helps anyone else. The issue is not to do with duplicate instances of the package at all, this is a false positive triggered by us using webpack's DefinePlugin to set the process.env.NODE_ENV to staging for our staging build.
However, in webpack the mode (see https://webpack.js.org/configuration/mode/), which sets the process.env.NODE_ENV, only accepts none, development and production as valid values. This was triggering an env check in the graphql package to fail and trigger this error message.
In our case, we need to differentiate between staging and production as our API endpoint differs based on this, but the solution we implemented is to not rely on the process.env.NODE_ENV, but to assign a custom variable on build (e.g. process.env.API_URL)
I would try to replicate the error locally and debug it:
try this:
rm -rf node_modules yarn.lock
# also remove any lock files if you have package-lock.json too
yarn install
# build the project locally and see if you got the error
I got this problem one time where I was working with Gatsby and 2 different themes where using different versions of GraphQL. Also be more explicit with the version (without caret) and check if the error persist.
do you have a repo youc an share? that would also help us to help you :)
While changing NODE_ENV to production might solve the issue, if you have different variables for each environment and don't want to mess with your metrics this is not an ideal solution.
You said you use webpack. If the build with the issue uses some kind of source-map in your devtool, you might want to disable that to see if the problem persists. That's how I solved this without setting my NODE_ENV to production.
I had a similar problem when trying to run Apollo codegen and was able to fix it by deduping my npm packages. Run this:
rm -rf node_modules && npm i && npm dedupe
I was having this problem so I switched to yarn, and after deleting node_modules and npm lockfile, then running yarn, the problem went away :-).
I ended up here because I use the AWS CDK and the NodejsFunction Construct. I was also using bundling with minify: true.
Toggling minify to false resolved this for me.