I highly doubt this is a Jest issue, but it's where the issue is popping up, so here goes.
My team is using Jest for tests. Today, I was writing tests, something I hadn't done in a project repo for about a week. When running the tests today, they all failed. I noticed that all the double quotes were being encoded like so:
Expected value to be (using ===):
"{\"data\":\"Important data\"}"
Received:
"{"data":"Important data"}"
Previously, the tests all ran and passed fine.
For my own sanity, I hopped unto the master branch and ran the tests, only to receive the same result. My teammates have also run the tests on their updated master branches but didn't have any issues.
It appears to be local to my machine. I delete node_modules and package-lock.json, and even re-cloned the entire repository. Unfortunately, I am still having the same issue and I'm not sure where to look. If this issue is remotely familiar to anyone, I'd love to hear suggestions.
Some maybe relevant info:
macOS 10.14.6
iterm2 (UTF-8 encoding)
node 8.10
npm 6.11.3
jest 24.8.0
Turns out the issue was with Node.js. I had not properly configured AVN to read from .node-version, causing the tests to run using another version of node.
Related
Working with Salesforce, org is authorised, everything works fine until it doesn't and there's no error code or anything.
In the morning I retrieved a few files I had to change, 10 minutes later when I needed to retrieve another one, it kept "Running SFDX: Retrieve Source from Org" for a few minutes and failed. Then again and again, whether I deploy something or retrieve, it just fails.
Closed, waited for it to sync, refreshed all lwcs, still the same problem.
You may have a sfdx-cli issue. There is a known issue right now with the version 7.150.0 reported here: https://github.com/salesforcecli/status
My team was having issues with our CI pipeline, and our fix was to use an older version. Once we updated our CI tool to grab https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/7.149.1/3881a5a/sfdx-v7.149.1-3881a5a-linux-x64.tar.xz extract the binary, and run the tool, our deploys started working successfully.
Check your local and CI tool with the sfdx --version command. If you are using the broken one, roll it back to the version that you need.
Recently, I ran into an issue at work. To summarize it, I am currently working on writing test cases for an internal Flutter project. This had been working fine for a while, but after my summer vacation, it started breaking. It took me a while to figure out what roughly was going on, but I hen discovered that running integration tests generated a file named generated_main.dart under .dart_tool/flutter_build/. This was working just fine when using integration tests, however, it caused unit tests to fail due to not even loading.
I managed to identify the relevant line of code in the generated file as line eight: import 'file:///tmp/flutter_tools.WJSDQT/flutter_test_listener.YHXZLS/listener.dart' as entrypoint;. The capitalized strings of random characters are indeed random, apparently referring to a temporary path that only exists for the unit test's duration. Unit tests throw (even though not always reliably): .dart_tool/flutter_build/generated_main.dart:8:8: Error: Error when reading '/tmp/flutter_tools.WJSDQT/flutter_test_listener.YHXZLS/listener.dart': No such file or directory.
Surprisingly, there seem to be no issues when deleting the generated file. I have now added a print statement to the integration tests that tells whoever ran them that they need to delete the generated file. But this is obviously not a good solution long-term. Is there a way to disable this behavior so that testing does not become unnecessarily more complicated?
My environment is Ubuntu 20.04 LTS with Flutter 2.5.0-5.1.pre on channel beta, using Android Studio 2020.3.1. I am not currently able to test for this behavior on other platforms. The program needs to run on Linux. The test package version is 1.17.10, the newest one compatible with other dependencies.
Thank you in advance for your time.
I am currently building a Visual Studio Code extension in typescript and I want to write some tests for it. My tests work fine using the npm test --silent command, there are just annoying errors saying Rejected cached data from file: and then a file name in my AppData\Roaming\Code\CachedData folder. I tried to look up the error but the issue doesn't seem to be well documented.
FYI: VSCode extensions use mocha as their default testing framework.
For whatever reason deleting the CachedData folder fixed the issue. Not ideal but it works.
Edit:
Summary, I tried to follow only the steps listed in the below two links as applies to windows:
https://github.com/mapbox/mapbox-gl-js/blob/master/CONTRIBUTING.md
https://github.com/stackgl/headless-gl#windows
Here I have reattached the screenshot of the commands that I had problems with:
https://imgur.com/RCQCNU5
One more step I took that I should mention is I also did not find the headless gl when I downloaded the repository, when the install headless gl command did not work I manually copied the file and put it in my local copy under the nodemodules directory thinking it would work but it didnt solve anything. I do think this is related to access issues but I dont know what else I should try to get it working?
First, let's clarify your problem: you want a version of mapbox-gl.js which contains a recently fixed bug.
Your best option is to just wait a couple of weeks for a release.
Failing that, you should build your own, from master. You don't need to set up a debug server for that. You can skip straight to the "Creating a Standalone Build" section.
If the steps for building on Windows don't work for some reason, you could set up a local virtual machine running Ubuntu and use that.
But honestly, just wait a couple of weeks. :)
Just in case some one else need to run this on local server.
After clone
Run npm install
npm run start-debug
It will start listening on port 9966.
Test the debug html files entering to
localhost:9966/debug/FILE_NAME_TO_TEST.html
I am trying to figure out how to package an unchanged fork of VS Code.
My first steps were to follow the electron application distubution documentation, which has not been successful. I also found this post, where another user had the same question. However, the vscode-win32 gulp task seems to have been replaced by x64 and ia32 versions, and when I try running these tasks they generate an out-vscode folder as opposed to a full electron project.
This led me to believe that I can use this new out folder (as well as node modules, packages.json, etc.) with the electron release being used by VS Code to mimic the resources/app folder from the installed version of VS Code in Program Files, however when I try running electron.exe using this method I get:
The factory method of "vs/code/electron-main/main" has thrown an exception TypeError: Path must be a string. Received undefined
In short, I have been struggling with this for a couple of days, and I am out of ideas. If anyone has packaged the project and can offer a suggestion for how to do so, I would really appreciate it.
SOLVED
The issue seemed to be due to being branched off of master as opposed to release. I'd assume there are changes in main that aren't accounted for in the gulp task.
For anyone confused by my post, the expected behavior for a successful build is for a folder named VSCode-win32-x64 to be generated in the directory where your vscode clone is located.