Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to jest 2 #1629

Merged
merged 46 commits into from
Aug 16, 2020
Merged

Migrate to jest 2 #1629

merged 46 commits into from
Aug 16, 2020

Conversation

AtofStryker
Copy link
Contributor

@AtofStryker AtofStryker commented Aug 1, 2020

A rebase of #1587 with browser tests.

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Build-related changes
  • Other, please describe:

Does this PR introduce a breaking change? (check one)

  • Yes
  • No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

If adding a new feature, the PR's description includes:

  • A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

This branch introduces moving VTU to jest over mocha, as well as using a few different strategies to run in the browser (discussed below)

@AtofStryker AtofStryker force-pushed the migrate-to-jest-2 branch 3 times, most recently from aa7852f to 68eddc5 Compare August 1, 2020 19:37
@AtofStryker
Copy link
Contributor Author

Wow, incredible work! This would have taken me much longer.

@lmiller1990 Thanks! COVID-19 in the USA has left me with a bit more time than I would usually have available 😅

I do not have the power to add contributors unfortunately. Can we just add the content of df19c1b and get this merged?

All good! I figured it couldn't hurt to ask 😄. We could merge df19c1b here as is as long as you and the team are comfortable with it.

So just to sum up:

  • we now have tests running in a browser via Jest + Jasmine combo (awesome).

✔️

  • there are problems with Vue 2.0 and 2.1 tests (you can still use the lib with 2.0 and 2.1, of course). I agree this trade off it worth it.

✔️

  • I had a look at df19c1b. Reviewing configuration is very difficult but if it's all passing than it should be white_check_mark great job!! merge !== release, and since the actual build process (rollup) did not change there should be little risk.

✔️
Summary seems spot on IMO! There is definitely a lot going on from a configuration standpoint, but the good news is it is pretty similar to what was previously standing. If there is something I can do, such as documentation or other additions, to make the configuration a bit more review-able/digestible, don't hesitate to let me know! Since we are trying to make this improvement last as long as possible (at least for VTU 1.x), we definitely want to make sure other contributors can consume/digest it.

There shouldn't be any immediate risk to these changes, as the bundles are the exact same between branches. I would double check me on that though 😉 . I am in no rush to release or merge by any means. Whatever it takes for us to ship this with confidence and to do it right.

I guess my only question is is there anything blocking merging this right now? It sounds like you have finished the job - while upgrading rollup would be nice, it shouldn't block this PR, right?

The only thing that I believe is of immediate concern is the removed build/release scripts in 28fffd8#diff-b9cfc7f2cdf78a7f4b91a753d10865a2L9 which can be seen here in the file diff. We can add that back in pretty easily, like here before merging.

@AtofStryker
Copy link
Contributor Author

AtofStryker commented Aug 5, 2020

As far as the rollup upgrade is concerned, it isn't necessary for this release, which we could merge it eagerly after just to make it easier to review separate from this chunk of changes. I had some time to look into the upgrade. The good news for us is that virtually nothing has changed for us between the plugin updates and rollup 2.x!

I performed those upgraded changes in AtofStryker@57c4a9c (Sorry, I couldn't help myself 🤣 ) and made a gist of that diff for the team/community review. None of the semver or acorn variables are actually used in the current bundle, and the other changes can be explained by https://github.com/rollup/plugins/blame/master/packages/commonjs/src/helpers.js#L38 and https://github.com/rollup/plugins/blob/master/packages/commonjs/src/helpers.js#L58 / rollup/plugins#206. That being said, when we do perform this upgrade, we should test the build and check for regressions, and I would recommend a minor release just in the rare case we would need to patch.

@AtofStryker
Copy link
Contributor Author

I also have a few other upgrades we can incorporate in separate PRs, including vuepress, core-js 3 (previously blocked by old vuepress and corejs 2.x is deprecated), and chalk (that was definitely the easiest one!). I actually don't think we need jsdom-global or jsdom any longer in the workspace as it ships with jest and was removed here. I might work on an eslint upgrade, and that should really be the final thing we need to do to get VTU 1.x dependencies in a more modern state (for now 🙊 )!

@AtofStryker
Copy link
Contributor Author

The only thing that I believe is of immediate concern is the removed build/release scripts in 28fffd8#diff-b9cfc7f2cdf78a7f4b91a753d10865a2L9 which can be seen here in the file diff. We can add that back in pretty easily, like here before merging.

I can add that commit to this branch, update the description, and mark it ready for review if that is the course of action we want to take 😄

@lmiller1990
Copy link
Member

@AtofStryker that'd be great, thanks a lot! Thank you very much for "owning" this feature 👍 excited to drop a tweet about this when we merge it, lmk your Twitter if you have one so I can tag you.

@AtofStryker AtofStryker force-pushed the migrate-to-jest-2 branch 4 times, most recently from c119513 to 58b257f Compare August 9, 2020 04:21
this.vm[key] === data[key] || this.vm.$attrs[key] === data[key]
this.vm[key] === data[key] ||
// $FlowIgnore : Problem with possibly null this.vm
(this.vm.$attrs && this.vm.$attrs[key] === data[key])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a few issues in CI recently in regards to this guy in vue 2.3. Looks like I introduced a small regression in VTU for setProps for vue version 2.3 in #1618. The stack trace was a bit difficult to track down, but this should fix the issues seen

After converting to Jest, browser tests were removed due to capatability issues. This reimplements
the browser tests with similar techniques.

All related webpack/loaders have been updated to use the latest stable
releases

Chrome/HeadlessChrome is now being used to run these tests over the deprecated
PhantomJS

Karma and Jasmine are being used as a test runner while leveraging Jest's expect/assertion and mock/stubbing libraries

Highly inspired by https://github.com/tom-sherman/blog/blob/master/posts/02-running-jest-tests-in-a-browser.md.

1629
Add back build scripts that were initially removed from jest migration
JSDOM and JSDOM-Global are no longer used with the removal of the mocha tests. JSDOM is still used
implicitly by jest.
@AtofStryker
Copy link
Contributor Author

@AtofStryker that'd be great, thanks a lot! Thank you very much for "owning" this feature +1 excited to drop a tweet about this when we merge it, lmk your Twitter if you have one so I can tag you.

@lmiller1990 sure thing! I appreciate you letting me be so involved in this and being so welcome to contributions. I'm a bad technologist and rarely touch social media these days 😆 . But I would definitely appreciate the tag. My twitter is https://twitter.com/AtofStryker.

As far as the PR goes. I made a few changes to address a regression here, but exercised CI after changes and it looks good to me. Build scripts are re added and I removed the jsdom and jsdom-global dependencies as they are no longer used. I think we are ready to rock and roll 🎸

@AtofStryker AtofStryker marked this pull request as ready for review August 9, 2020 04:48
@lmiller1990
Copy link
Member

I will get this merged this week.

@lmiller1990
Copy link
Member

lmiller1990 commented Aug 15, 2020

Ok! It seems like everything is working.

I am having many problems running this locally though. Linting failing...

$ eslint --ext js,vue .
Cannot read property 'range' of null
TypeError: Cannot read property 'range' of null
    at SourceCode.getTokenBefore (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/token-store/index.js:303:18)
    at checkSpacingBefore (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/rules/template-curly-spacing.js:52:42)
    at TemplateElement (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/rules/template-curly-spacing.js:117:17)
    at /Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/util/safe-emitter.js:47:58
    at Array.forEach (<anonymous>)
    at Object.emit (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/util/safe-emitter.js:47:38)
    at NodeEventGenerator.applySelector (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/util/node-event-generator.js:251:26)
    at NodeEventGenerator.applySelectors (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/util/node-event-generator.js:280:22)
    at NodeEventGenerator.enterNode (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/util/node-event-generator.js:294:14)
    at CodePathAnalyzer.enterNode (/Users/lachlan/code/projects/vue-test-utils/node_modules/eslint/lib/code-path-analysis/code-path-analyzer.js:608:23)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
$

Hm.

Edit: Ok, this solved it: babel/babel-eslint#681 (comment)

@lmiller1990
Copy link
Member

lmiller1990 commented Aug 15, 2020

When I do yarn test locally is hangs on the Karma tests; is this the case for you locally @AtofStryker ? The karma process doesn't close. Is that normal?

@AtofStryker
Copy link
Contributor Author

AtofStryker commented Aug 15, 2020

When I do yarn test locally is hangs on the Karma tests; is this the case for you locally @AtofStryker ? The karma process doesn't close. Is that normal?

@lmiller1990 Yeah that is expected. Karma tests by default run in watch mode, so when changes are made (locally) the tests rerun. If we don't want that behavior, we can just set singleRun to true here

I am having many problems running this locally though. Linting failing...

Glad babel/babel-eslint#681 (comment) solved it. I didn't have issues linting locally, but I also reinstalled from lock after deduping. That also might help, but changing the rule should work just as well

I'll give the changes a pull locally and see if I have any issues

Edit: changes locally look good on my end with the latest commit.

@AtofStryker
Copy link
Contributor Author

BTW @lmiller1990 were you having any other issues or was it just the linting?

@lmiller1990
Copy link
Member

lmiller1990 commented Aug 16, 2020

Everything else works great. I am guessing singleRun is somehow set to true on CI (or it would hang forever)?

It might be good to have it set locally by default (can you make that change?) I feel like other people contributing will have the same problem I just did.

Other than that, happy to merge and do a release!

Set singleRun option in karma to true locally and in CI so the test process always terminates when
finished
@AtofStryker
Copy link
Contributor Author

Everything else works great. I am guessing singleRun is somehow set to true on CI (or it would hang forever)?

@lmiller1990 correct. The config is utilizing the circle var process.env.CI, which Circle sets to true when running in CI.

It might be good to have it set locally by default (can you make that change?) I feel like other people contributing will have the same problem I just did.

Definitely! On revisiting, the watching behavior was probably a poor choice on my end 😆 . Definitely don't want others to run into snags or problems when contributing. We can just set singleRun: true by default so we don't have to worry about any hanging. I have implemented in afad86e

Other than that, happy to merge and do a release!

Sweet! We should be good to go then! 🎉 Once we get this merged in, I will open a few other PRs for some other library upgrades in, such as vuepress, eslint, rollup, etc. They are relatively minimal compared to this PR. Hopefully these changes allow for less cognitive overhead and context switching between the VTU 1.x and 2.x workspaces for contributors and the team 😃

@lmiller1990 lmiller1990 merged commit 60c1bce into vuejs:dev Aug 16, 2020
@lmiller1990
Copy link
Member

It's merged!!!! 🎉 thanks!

@lmiller1990
Copy link
Member

It's out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants