Consider type local as the default interceptor type

[diego-aquino]

We could simplify our API to consider type: 'local' by default when creating an interceptor, making type an optional parameter.

Pros:

• Simpler to get started;
• Less mental overhead of comparing local vs remote interceptors when just starting with Zimic;
• Will work in most testing scenarios.

Cons:

• Users might never realize that type: 'remote' exists

To help with the only con I see, we could improve our documentation to encourage starting with a local interceptor, without passing any type, and point to other pages explaining advanced use cases with local and remote interceptors.

[emanamoura]

I think it is a nice thing to do, this appears to me a good first contribution, is this task open to contribute ?

[diego-aquino]

Hey, @emanamoura! Thanks for the interest in contributing to Zimic!

Right now, I'm working on the following issues to make it easier to contribute:

• Contributing guide #18
• Create issue and discussion templates #386
• Simplify test setups and suites to make contributions easier #412

The most important one is the contributing guide showing how to fork and run the project, an overview of the packages and architecture, and our philosophies and guidelines. Would you like to wait for them before taking implementation tasks?

I expect to add the contributing guide and the issues/discussions templates by next week.

---

In the meantime, there are two tasks related to the documentation and the examples that may be good first issues too. Let me know if you are interested in working on them.

• Add "Open in Stackblitz" links to examples #343
• Update examples to only ignore requests to 127.0.0.1 in logs #406

[emanamoura]

Hi @diego-aquino , yes ! I can wait. Could I get #406 ?