I'm trying to do a very simple test using mocha (no config files, no additional flags, just mocha, yarn2, and testee.js file), but it always give me 0 passing. Hell, it won't even run any file!
// testee.js
console.log('test') // No output
describe('something', () => {
it('Should run', () => {
console.log('test 2') // No output either
})
})
$ yarn mocha testee.js
0 passing (1ms)
Tools I'm using:
Mocha 9.0.2
Yarn Berry 2.4.2
Is mocha unsupported by Yarn 2? Should I use something else? I always use mocha for all of my test files, maybe it's time to migrate if that really is the case.
Note: I tried using yarn 1 and it worked flawlessly. Also, Mocha found the testee.js file, otherwise it would give me not found error instead of 0 passing
Mocha 9 uses ESM-first approach to imports
https://github.com/mochajs/mocha/releases/tag/v9.0.0
Yarn 2+ with the default PnP install scheme does not support ESM yet, because Node API lacks some features to make this possible
For the time being, if you want to use Mocha 9, you have to use node_modules install scheme with Yarn 2+ by changing your config to:
.yarnrc.yml
nodeLinker: node-modules
...
and running yarn to reinstall your project with node_modules
You can track ESM support for Yarn PnP here:
https://github.com/yarnpkg/berry/issues/638
Related
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 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.
Error
Error: /home/travis/build/ElectronicaGitHub/pictureAvenue/node_modules/jest-
cli/node_modules/jsdom/node_modules/contextify/build/
Release/contextify.node: invalid ELF header
That's happening when i'm trying to start JEST tests, it's just example test from JEST tutorial and looks like
jest.dontMock('../sum');
describe('sum', function() {
it('adds 1 + 2 to equal 3', function() {
var sum = require('../sum');
expect(sum(1, 2)).toBe(3);
});
});
Locally test with JEST runs fine.
Tried to start mocha tests on travis-ci and it's ok!
But my project on ReactJS and i they advise to use JEST for tests.
How to fix that problem?
Found your project on GH: https://github.com/ElectronicaGitHub/pictureAvenue
Almost guaranteed that this is because you checked in the node_modules folder. This should be downloaded by each consumer of the project, using npm install. Add a .gitignore file to the root of your project with the following content:
node_modules
Before you do this, you'll need to do:
rm -fr node_modules && \
git commit -a -m 'remove node_modules from source control' && \
git push origin master
Then add your .gitignore file and do another commit.
While you're at it, it looks like you're also checking in your sass-cache (.sass-cache\*). You'll want to do the same thing.
Final thoughts:
Typically source control is great for any artifact or code, it is not great for things that are often OS dependent (like node_modules) or host dependent (.sass-cache).
Hope that helps.
Running yeoman server:test opens Jasmine in my browser and says that my test has passed. Now I want to try the same, but without a browser - using PhantomJS on the CLI. Unfortunately, running yeoman test only throws a:
Running "jasmine:all" (jasmine) task
Running specs for index.html
>> 0 assertions passed in 0 specs (0ms)
Why doesn't it find any tests, even though everything is included in my test/index.html and works pretty well using yeoman server:test?
I used yeoman init jasmine:app --force over my project and adjusted the Gruntfile.js as described here. It looks like that:
...
// headless testing through PhantomJS
jasmine: {
all: ["test/**/*.html"]
},
...
// Alias the `test` task to run the `jasmine` task instead
grunt.registerTask("test", "jasmine");
...
Note: My tests are written in CoffeeScript.
After some research I found out that PhantomJS is not able to find the files at the same location as ´yeoman server´ or yeoman server:test does.
I precised my question in another thread: Running tests in both headless and browser
The info on this page seems less-than-forth-coming -- https://github.com/kof/node-qunit. I've got a setup where I installed nodejs and installed the node-quit module. I have test runner and executed the command node /path/to/runner.js. Below is an example of my setup. Any ideas or examples on how to do this or maybe I'm using it wrong. I previous ran qunit tests using Rhino and EnvJs without any issues but I figured I try nodejs since I using it for other things and the packaging system can be scripted in my build. Maybe I missing an option to node to include Qunit or some environment variable not set -- that would make sense.
File Structure
node/
public/
js/
main.js
tests/
js/
testrunner.js
tests.js
Installation
cd node
npm install qunit
This will now update the file structure.
node/
node_modules/
qunit/
tests/js/testrunner.js
var runner = require("../../node/node_modules/qunit");
runner.run({
code : "/full/path/to/public/js/main.js",
tests : "/full/path/to/tests/js/tests.js"
});
tests/js/tests.js
test("Hello World", function() {
ok(true);
});
Command
node tests/js/testrunner.js
It appears that you need to use full paths to the main.js and tests.js files and also include a relative path to the qunit module. I updated the code above as an example for others.