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

Jest 26? #247

Closed
jnardone opened this issue Jun 24, 2020 · 13 comments
Closed

Jest 26? #247

jnardone opened this issue Jun 24, 2020 · 13 comments

Comments

@jnardone
Copy link

Can we update peer dependencies to use Jest 26? This would also mean moving ts-jest to 26.x.x.

@lmiller1990
Copy link
Member

lmiller1990 commented Jul 2, 2020

Didn't Jest 26 just come out?

I wonder if there is any breaking changes we need to be aware of.

Also, is there any strong benefit to change the peerDependency version? It's "^25", or "at least 25". That said, it is good to keep dependencies up to date.

One thing to note is 4.0.0 is still in "beta" - if you want to make a PR updating the dependencies, I think we can move to a release candidate (not sure if this really has any major implications, I only joined the project recently and can't really see any breaking changes from 3.0.0 to 4.0.0 anyway).

@jnardone
Copy link
Author

jnardone commented Jul 2, 2020 via email

@lmiller1990
Copy link
Member

Ok. I think we need a good strategy for versions, and if there are any associated breaking changes.

We could continue discussing this here: #246

@jnardone
Copy link
Author

jnardone commented Jul 2, 2020

One thing would be to version in conjunction with jest. So vue-jest 25.x is for jest 25.x, 26.x for 26.x, etc.

@lmiller1990
Copy link
Member

lmiller1990 commented Jul 2, 2020

I had this idea - I like this. How to specify Vue 2 and Vue 3 though? The codebases are quite different - the compiler is completely separate.

@TheJaredWilcurt
Copy link

TheJaredWilcurt commented Jul 17, 2020

I've been pinning all my repos to "jest": "24.9.0" until they can fix the color diffing bug that happens on many OS's, terminals, and CI's. This bug can make Jest 25+ unusable for many users, including those with disabilities/impairments.

@ahnpnl
Copy link

ahnpnl commented Jul 29, 2020

How about following enzyme adapter way. For example vue-jest-3 is a package on npm which is different from vue-jest-2.

In vue-jest-3 package, you can have: v24, v25, v26 etc which stands for jest compat

The downside is more maintenance, but probably automatic CI CD can help.

@lmiller1990
Copy link
Member

I think this is a good idea. Yesterday some code was merged to 4.x but not 5.x - having two effectively different libs in one repo doesn't make sense.

I will work on separating the two repos soon. Then we can follow the pattern of matching the Jest version.

@ahnpnl
Copy link

ahnpnl commented Jul 30, 2020

I think monorepo or yarn workspace can help to maintain things like that. You can check how jest did. The structure will be like:

  • packages
    • vue-jest-2
    • vue-jest-3
    • vue-jest-4
      ...

Then you can configure CI CD or manually publish each independent package.

@vvanpo
Copy link
Contributor

vvanpo commented Aug 1, 2020

Is there a reason we constrain jest to a specific major version? I've been using vue-jest with Jest 26 without problems, so clearly a version constraint like ^25 || ^26 would work. Likely we could go even laxer, like >= 24. I don't think we should be over-constraining peer dependencies unless we have a specific compatibility reason for doing so.

@vvanpo
Copy link
Contributor

vvanpo commented Aug 1, 2020

In vue-jest-3 package, you can have: v24, v25, v26 etc which stands for jest compat

If by v24, etc. you mean those would be version tags, that would limit vue-jest to only publishing breaking changes at the same cadence as jest. That's probably not a big deal, because we likely don't have much of a need for making breaking changes all that often, but still doesn't make too much sense IMO. In all likelihood the changes between Jest version compatibility of v24 vs v26 are fairly minimal, and if there are any issues we can probably manage them with conditionals checking the currently loaded Jest version. Having three separate branches means that every bug fix and feature will need to be backported twice. I think we'd be better off just updating our test runner to run 3 times, once for each version of Jest v24, v25, and v26. That would help us ensure vue-jest remains compatible. I'm happy to make a PR for that if that sounds like a good idea.

Yesterday some code was merged to 4.x but not 5.x - having two effectively different libs in one repo doesn't make sense.

@lmiller1990 if you're referring to my changes to Sass' importer, I'm sorry about that my intention was not to cause the two branches to diverge. I fully intend to open another PR to cherry-pick those changes to 5.x, but I'd like to explore a different solution first (webpack-contrib/sass-loader#873) and am waiting to hear how that pans out.

@lmiller1990
Copy link
Member

lmiller1990 commented Aug 1, 2020

@vvanpo Yep no problem, I don't mind if we diverge a bit - the codebases between master and next are not too different, we should cherry pick the commits, but no rush - I think we should definitely figure out how we can make this entire code base more maintainable and share common features across Vue 2.x and 3.x.

Regarind Jest versions, I am in the same position as you - I have noticed no problems with both Jest 25 and 26, but there seems to be a pretty common convention with Jest transformers to pin their versions to Jest. Seems like it's good to follow the convention.

That said it might just add more complexity. Ideally we want to support both Vue 2.x and Vue 3.x across each version of Jest. I have no idea what the differences are in Jest 25 and 26, maybe we can just support the latest major version of Jest (it is really difficult to upgrade Jest versions? I don't think so? I've always just added the latest Jest without even thinking about what version I'm adding).

Ideally we will separate the Vue 2.x and Vue 3.x specific logic and use the same transformers (eg for sass, coffeescript, whatever) across both integrations. Maybe a monrepo with something like

- packages
  |- vue-2
    |- process.ts
  |- vue-3
    |- process.ts
  |- shared
    |- transformers
      |- style
        |- sass
      |- template
        |- pug
      |- script
        |- typescript
        |- coffeescript

etc.

@lmiller1990
Copy link
Member

4.x is now in RC and on Jest 26.

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

No branches or pull requests

5 participants