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

Update all dependencies to latest #42

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

jasco
Copy link

@jasco jasco commented Oct 9, 2020

This updates all the project dependencies to latest, including porting to Typescript 4.

All the tests and ci pass.

When reviewing, note in particular the destructuring immutable copy that was added in intermock.ts at line 334. The Typescript fields are now declared readonly so this somewhat complicated casting and destructuring approach, which basically should mirror what was there previously, was used to do a deep copy-update.

Joel Steres added 4 commits October 9, 2020 01:07
… dependency.

The jest types where conflicting with mocha types. There were no
references in the project to jest.
Addresses changed property name and update to record with immutable fields.
Typescript 4 NullKeyword is now a subtype of the LiteralType
@google-cla
Copy link

google-cla bot commented Oct 9, 2020

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@jasco
Copy link
Author

jasco commented Oct 9, 2020

@googlebot I signed it!

@ryanmcdermott
Copy link
Member

From a cursory glance this looks great! I'll scrutinize a little deeper in the coming week. For better and worse, I rely solely on the unit tests rather than insights from real-world usage due to its still limited prevalence in the wild. All that to say, I may write a few new unit tests to see if there's anything this might have missed with changes in TS 4.

This leads me to conjecture that it might be time to make this a major version release. For the most part, the tool has been stable in terms of new PRs, after all it's been over a year since its launch. Some new features get added and new language constructs are handled, but by and large this feels fairly concrete. A major version release will provide the greatest benefit in changes such as this PR where the underlying TS target is upgraded.

What are your thoughts regarding this 1.0.0 major version idea?

@jasco
Copy link
Author

jasco commented Oct 9, 2020

Based on the possibility that the dependency changes might represent a breaking change for some, the major version idea makes a lot of sense. As far as a 1.0.0 release, in my very limited exploration (I just found this project yesterday), I have seen a few rough edges (possibly user errors) that might ideally be working in a 1.0 release.

The most notably problems:

  • I have observed a few cases where an interface member that references another interface is populated with an empty object rather than a fake. (At least a couple of cases involve references to interfaces that are import from a separate file. (Yes, they were parsed.) The secondary interface do fake properly when requested from intermock directly.

  • In a number of cases, I have observed arrays mock with empty objects rather than fake objects. I locally fixed the case for an array of enums, but I don't understand the Typescript code well enough to fix for the general case. I'm rather suspicious of the array's default case handling and suspect it may be the source of the problems. I looked at expanding the array kind cases to pull the data from the cached types, but I encountered typing problems reusing the process.... functions from elsewhere in the code and it quickly got too complicated for me to know if what I was doing was correct.

An aside,

  • When I added a function to an interface, intermock gave me an unsupported error. I was inspired to try this because I saw Typescript function SyntaxKind inside the code. I don't think this is a problem, but it might merit a disclaimer in the documentation. (Or it might be cool if it generated an empty function that matched the prototype.)

@jasco
Copy link
Author

jasco commented Oct 9, 2020

I added a issue for the first case I mentioned above, #43.

A correction regarding the second case above, it seems like I may have encountered two cases. Most of the cases I observed were actually cases where the object was declared in another file, like the first issue. The other case was when a type alias was referenced even when declared in the same file. I added this second variant as issue #44.

This was referenced Oct 9, 2020
@developer239
Copy link

@jasco @ryanmcdermott Is anyone going t merge this? Also is the issue with empty objects fixed? This library seems promising but right now the types are not generated correctly - in most cases - so it is also useless.

I could maybe help if you create an issue and describe at least roughly where the problem is. 🙂

@EliazTray
Copy link

Any update now?

  • Recursive type supported.
  • referenced object supported.

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.

4 participants