Vscode-jest: next release

[connectdotz]

This is to track the next release:

multi-root workspace support

• [x] merge #379
• [x] fix status bar (#447)
• [x] fix output file generation for concurrent Runner in jest-editor-support (jest-editor-support/#9, #447)
• [x] upgrade jest-editor-support dependency to pick up the latest version. (#447)

sidebar support (postponed)

• [ ] merge #357
• [ ] support hierarchical tree structure (like the Explorer)

additional features

• [x] restart command (#441)
• [x] template-literal-string support (#447)
• [x] fix debug break points problems for some js projects (#459)

technical debt

• [x] merge #446 (deprecate vscode.previewHtml)
  

  - [x] address security alerts

Due to the scope of the changes, we created a beta branch so more people can help to address the remaining issues and speed up the release. If you are interested to help, please submit PR against beta branch or help us testing. Thank you 🙏

In addition to testing new features listed above, would really appreciate help for regression testing:

• [ ] with older vscode (prior to 1.34)?
• [ ] with older jest (prior to 24.7)?
• [x] in window env?

[connectdotz]

@escaton when I was testing multiroot in beta, noticed this issue:

The test result parsing has a random race condition, and tests are not being correctly decorated, especially when the system is under a bit of stress. After taking a closer look at the console output, it seems all the jest runners output to the same tmp file!

spawning process with command=/Users/vsun/ConnectDotz/projects/dots/packages/dots-google-photos/node_modules/.bin/jest, args=--json,--useStderr,--outputFile,/var/folders/kv/r07v4crd5qx_kd6959jjdmb80000gn/T/jest_runner.json,--no-color
...
spawning process with command=/Users/vsun/ConnectDotz/projects/dots/packages/dots-message/node_modules/.bin/jest, args=--json,--useStderr,--outputFile,/var/folders/kv/r07v4crd5qx_kd6959jjdmb80000gn/T/jest_runner.json,--no-color

The output file is generated by jest-editor-support.Runner and looks like it didn't anticipate concurrent runners 😰. To make the matter worse, jest-editor-support has been refactored and moved out of jest repo recently but vscode-jest is still using an older version whose source code doesn't exist anymore 😱

This issue is a show-stopper; I think we will need to fix jest-editor-support and upgrade vscode-jest's depenency... I will add a new action item to track.

[escaton]

Looks like it affects not only multiroot scenario. Two separate vscode instances would share the same Runner now and so will concurrently write to that log.

[escaton]

Do you know what was the reason to communicate with runner through fs instead of stdOut/stdErr? Just omiting --outputFile arg should work, or am i missing something?

[connectdotz]

I am guessing a json file is easier to parse and probably with more stable format than stdin/stdout

[kresli]

I apologise for stupid question, but how can I run extension in beta version? couldn't find any mention in docs.

[connectdotz]

similar to how you will run a development build based on master branch... just switch to beta branch after git clone.

[muratg]

@kresli Check out the last section here: https://github.com/jest-community/vscode-jest/blob/master/CONTRIBUTING.md

[roni-frantchi]

Followed the instructions posted by @muratg and @connectdotz so I'd be able to give beta a try.
Our project structure is something like:

| + frontend
|  \
|     | - jest.config.js
|
|+ backend
  \
   | + service-a
   |  \
   |   | - jest.config.js
   |
   | + service-b
   |  \
   |   | - jest.config.js
   .
   .
   .

I have tried to setup the plugin like so:

{
    "jest.enabledWorkspaceFolders": [
        "frontend", 
        "backend/service-a", 
        "backend/service-b"
    ]
}

My jest.config.jss are all an extension of:

require('dotenv').config({ path: 'tests/.env' });

module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'node',
  restoreMocks: true,
  clearMocks: true,
  modulePaths: [
    'node_modules',
    '.',
  ]
};

Yet it seems like my configuration of using ts-jest does not apply as all I'm getting is something in the lines of:
```est suite failed to run

Jest encountered an unexpected token

This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.

...

on-auth0-login.spec.ts: Unexpected token, expected "," (36:71)

  34 |       await Account.create({ userId });
  35 |       // eslint-disable-next-line @typescript-eslint/camelcase
> 36 |       const response = await handler({ body: { user_id: userId } }, {} as any, null);
     |                                                                        ^

```

I'm assuming my config file didn't apply as it seems ts-jest preset wasn't used and jest attempted to run the .ts file, but I'm not sure what I did wrong.

Would be happy to provide you with any other details that might be useful.
Thanks.

[connectdotz]

@roni-frantchi thanks for testing the beta, the multiroot utilize vscode's multiroot-workspace framework, meaning it expects your vscode project will have this structure (in vscode's explorer, not actual file system):

| + frontend
| + service-a
| + service-b
  ```
so your ject config would be:

{
"jest.enabledWorkspaceFolders": [
"frontend",
"service-a",
"service-b"
]
}
```
hope this help, let us know how it goes...

[roni-frantchi]

Thanks @connectdotz !
Didn't realize that I need to import individual projects of my monorepo as a separate folder to the workspace - I naively checked out my monorepo and imported the root directory of it to VSCode.
I'll try it out as soon as I get a chance and report right back

[roni-frantchi]

@connectdotz no luck.
workspace.json:

{
    "folders": [
        {
            "path": "/...../service-a",
            "path": "/...../service-b",
            "path": "/...../service-c",
        }
                 // ...
    ],
    "settings": {
        "jest.enabledWorkspaceFolders": [
            "service-a",
            "service-b",
            "service-c"
        ]
    }
}

Output:

Exception raised: Process failed: spawn jest ENOENT
Finished running all tests. Starting watch mode.

Exception raised: Process failed: spawn jest ENOENT

Exception raised: Process failed: spawn jest ENOENT

Exception raised: Process failed: spawn jest ENOENT

Exception raised: Process failed: spawn jest ENOENT

Exception raised: Process failed: spawn jest ENOENT
Starting Jest in Watch mode failed too many times and has been stopped.
Consider either add this workspace folder to disabledWorkspaceFolders setting or add needed folders to enabledWorkspaceFolders
 see troubleshooting: https://github.com/jest-community/vscode-jest/blob/master/README.md#troubleshooting

Not sure what's going on...

[escaton]

@roni-frantchi where do you have your jest binary installed?

[roni-frantchi]

@escaton the binary is in service-a/node_modules/.bin/jest while jest resides in <project-root>/node_modules - we're using Yarn Workspaces to manage our monorepo dependencies.

[roni-frantchi]

I was able to get the ability to debug via the spec by setting these launch.json:

       {
            "type": "node",
            "name": "vscode-jest-tests",
            "request": "launch",
            "program": "${workspaceFolder}/node_modules/.bin/jest",
            "args": [
                "--runInBand"

            ],
            "cwd": "${workspaceFolder}",
            "console": "integratedTerminal",
            "internalConsoleOptions": "neverOpen",
            "runtimeVersion": "8.10.0"
        }

However it seems the watch tests still fail due to wrong node version used...

[roni-frantchi]

@connectdotz I do use nvm, yes

[connectdotz]

I was able to get the ability to debug via the spec by setting these launch.json

which launch.json is this? is it in project root, workspace setting or the specific folder?

However it seems the watch tests still fail due to wrong node version used...

has the error changed? you were reporting errors about jest not found, is it now reporting something else ?

If you can create a sample project that will probably make it easier to diagnose...

[yoyoys]

this should relate to #254

[roni-frantchi]

Sorry for the very late response @connectdotz . Was on holiday.

which launch.json is this? is it in project root, workspace setting or the specific folder?

This is the launch.json workspace setting.

has the error changed? you were reporting errors about jest not found, is it now reporting something else ?

Yes, with the luanch.json shown above, Jest was found.
The watched tests now fail with an error of not being able to find proper version for some modules (in most cases, sqllite).
These errors are shown when the wrong node version is used and as such the right module can't be found.
I suspect this setting : "runtimeVersion": "8.10.0" somehow does apply when I click on the debug scope but does not apply for the watch.
Either that, or it does not apply at all, and since I'm using NVM and the debug opens a terminal, it looks for my .nvmrc and sets it properly regardless of that setting:

Found '/Users/roni/dev/env0/.nvmrc' with version <8.10.0>
Now using node v8.10.0 (npm v5.6.0)

I'll try and create sample project.

[connectdotz]

just released 3.0.0 pre-release, now you should be able to test with pre-build binary, please give it a try and let us know if there is any issue.

[connectdotz]

@escaton, @blikblum, @vdh, @qalex thanks for your contribution to this release, it won't be possible without you 🙏 . We look forward to seeing you more in this repo!

[connectdotz]

@seanpoulter @stephtr in the process of building the vscode package, I noticed a few things:

• the binary size has grown quite a bit, vscode packaging is not very good at removing the unrelated dev dependencies. If the installation time/size becoming an issue, we might need to consider bundling with webpack...
• the newly separated jest-editor-support introduced jest-config dependency in the Settings.js, which we are not using in vscode-jest any more. jest-config brought in lots of jest dependencies that also increased the package size. Again, this is something we can consider optimizing if needed.
• github now raised a lot of security warning that I think we should address, how do you guys feel about using the automated security fix?

BTW, if you have access to windows machines, can you try 3.0.0 pre-release with it? thanks.

[stephtr]

Installing the extension via the store produces a node_modules folder with more than 4000 files and 35 MB. For me that would be reason enough to try switching to webpack. Its tree shaking feature maybe also solves the issue with jest-config.
If there is no one who woulds like to take a look at that, I could give it a try.

Since we are already talking about tooling, could we also talk about using semicolons? I have hardly ever seen any JS/TS project not using them as line endings.

Concerning the security alerts: If the automated pull requests pass the test and according to the changelog don't introduce any breaking changes, I would just merge them (without further manual testing, which probably is being done when releasing a new build). For the security alerts not being fixed by automated PRs we should probably take a look at whether we can manually bump the dependents within our package.json.

[connectdotz]

If there is no one who woulds like to take a look at that, I could give it a try.

that would be awesome! 👍

Since we are already talking about tooling, could we also talk about using semicolons?

I would definitely second that, but that will be touching every single file, learning from my past mistake, let's make sure this time we do it in a separate standalone PR.

Concerning the security alerts: If the automated pull requests pass the test and according to the changelog don't introduce any breaking changes, I would just merge them (without further manual testing, which probably is being done when releasing a new build).

as long as there is a before-release, eat-out-own-dog-food testing, I completely agree we don't need to manually test each security alert PR.

[stephtr]

Unfortunately compilation using webpack fails due to jest-config. It seems like we first have to adapt jest-editor-support and/or jest-config for that.

I would definitely second that, but that will be touching every single file, learning from my past mistake, let's make sure this time we do it in a separate standalone PR.

...and when there are no other larger PRs around.

[connectdotz]

Unfortunately compilation using webpack fails due to jest-config. It seems like we first have to adapt jest-editor-support and/or jest-config for that.

urgh... ok, let's deprecate Settings.js in jest-editor-support and its dependencies, do you want to submit a PR (hey a good opportunity to test 3.0.0 on windows) and I will quickly review and cut a new release. Maybe once that was out the binary size will come down that we might not even need to do webpack right now.

[stephtr]

urgh... ok, let's deprecate Settings.js in jest-editor-support and its dependencies, do you want to submit a PR (hey a good opportunity to test 3.0.0 on windows) and I will quickly review and cut a new release. Maybe once that was out the binary size will come down that we might not even need to do webpack right now.

Another possibility was to just exclude jest-config from compilation, webpack then works (see #471). We could still get rid of Settings.js, but that has no priority and changes hardly anything after webpacking it. I would still use webpack, since the impact on dev compilation time is small but it nevertheless decreases the final extension size.

[connectdotz]

ok, merged the webpack PR, awesome job @stephtr! 👍

look like you also addressed all the security alerts, are they all in beta now? If they are, I will cut a 3.0.1

[stephtr]

look like you also addressed all the security alerts, are they all in beta now?

Yes, they should be.

[connectdotz]

ok, 3.0.1 is out.

do you guys have any objection to merge beta to master now, and if we didn't see any issue in the next few days, release it to vscode marketplace next week.

[stephtr]

I would be fine with that.

[connectdotz]

[status update]

trying to publish to vscode marketplace but bumpped into some permission issue, working with @orta on it...

[stephtr]

OK, but then let's wait shortly to fix the newest security issues.

[connectdotz]

hmmm... we could generate the PRs for the security fixes but I would prefer not to merge them in this release (3.0.2), otherwise, we will have to test it again and further delay the release...

However, we could release another minor release (3.0.3) soon, which could include these security fixes and potential production issue/fix.

[stephtr]

Ok, I will prepare the security patch PR.

[stephtr]

@connectdotz Do you know what the micromatch dependency is being used for? Is it even in use? We would at least have to update it to a more recent major version in order to get rid of one security issue (if we don't remove it at all).

[connectdotz]

looks like this dependency was introduced by #139 and is no longer used, should be safe to remove from package.json. you might also want to remove the typings/micromatch.d.ts

[connectdotz]

finally, v3.0.2 is published

Let's all keep an eye on the issues for the next few days, hopefully, this is an uneventful rollout... 🤞