Sharing scalars between modules with Chimp

Previously if you wanted to reuse the same scalar in different modules you had to redefine it in all of them.
That made sense from the modularity point of view - after all the modules are supposed to be self-sufficient. But scalars are such low-level building blocks that they are usually shared and it made sense to come up with a new pattern.
We discussed and came up with a backward-compatible solution with @jmvtrinidad and @ovidiup13.
Now, starting with version chimp@4.1.2 if you just want to use a scalar in a given module, but do not want to redefine it, use @predefined directive.

For example:

src/global/global.graphql

scalar JSON
scalar Date

src/moduleOne/moduleOne.graphql

type WithJSON {
  id: ID!
  json: JSON!
}
scalar JSON @predefined

src/moduleTwo/moduleTwo.graphql

type WithDate {
  id: ID!
  date: Date!
}
scalar Date @predefined

will result with src/global/scalars/Date.ts and src/global/scalars/JSON.ts files generated and connected to the apollo resolvers object. moduleOne and moduleTwo will NOT generate their versions of scalars but will be using the ones implemented in src/global/scalars/.

Obviously if you extract a given module to a separate micrograph you will need to remove the @predefined keyword and reimplement the scalar. If you are not sure what am I talking about here - don't worry, you probably don't need to. :-)

Let me know if you have any questions or thoughts in the comments below.


Let us help you on your journey to Quality Faster

We at Xolvio specialize in helping our clients get more for less. We can get you to the holy grail of continuous deployment where every commit can go to production — and yes, even for large enterprises.

Feel free to schedule a call or send us a message below to see how we can help.

User icon
Envelope icon

or

Book a call
+
Loading Calendly widget...
  • Add types to your AWS lambda handler

    Lambdas handlers can be invoked with many different, but always complex, event arguments. Add to that the context, callback, matching return type and you basically start listing all the different ways that your function can fail in production.

  • How to expose a local service to the internet

    From time to time you might need to expose your locally running service to the external world - for example you might want to test a webhook that calls your service. To speed up the test/development feedback loop it would be great to be able to point that webhook to your local machine.

  • For loops in JavaScript (vs _.times)

    From time to time I still see a for loop in JavaScript codebases. Linters are frequently angry about them. Let's see how we can replace them.