search

mswjs / source

Generate MSW request handlers from various sources (HAR files, OpenAPI documents, etc).
https://source.mswjs.io
134 stars 5 forks source link

feat: introduce tsup for bundling #25

Closed weyert closed 2 years ago

weyert commented 2 years ago

Added the package tsup to assist in bundling @mswjs/source-package so it both supports CommonJS and ESM modules. The package.json file has been modified so the appropriate properties for the modern exports-approach of exporting, and the older main-module combination.

During building and running the tests the fromOpenApi had issues to pass the tests or build due to the way the SwaggerParser utility class was exporter. The code has been updated so it refers to the deferences-function via SwaggerParser.deferences() instead of trying to instantiate the class.

For this reason the tsconfig.json has been updated so that it enables esModuleInterop and allowSyntheticDefaultImports after this change the package build and bundled successfully with tsup and passed the unit tests, before errors like below were shown:

    src/fromOpenApi/fromOpenApi.ts:16:35 - error TS2351: This expression is not constructable.
      Type 'typeof SwaggerParser' has no construct signatures.

    16   const specification = await new SwaggerParser().dereference(document)
                                         ~~~~~~~~~~~~~
weyert commented 2 years ago

I have tested these changes by run the build-command and copy the contents of the generated lib-directory to the lib-directory in my project that uses this package and then wrote the following Jest unit test:

import { fromTraffic } from '@mswjs/source'
import { default as json } from './__data__/health-check.json'

  it.only('should throw exception when all services are unavailable', async () => {
    server.use(
      ...fromTraffic(json),
      // rest.get('https://localhost:30001/-/health', (_req, res, _ctx) => {
      //   res.networkError('Network Error')
      // }),
      // rest.get('https://localhost:30002/-/health', (_req, res, _ctx) => {
      //   res.networkError('Network Error')
      // }),
    )

    await expect(controller.check()).rejects.toThrow('Service Unavailable Exception')
  })

For me, after these changes, the above unit test was passing without errors. The project is a Nest.js project using Typescript.

Note I currently don't have a ESM only project ready to test if the ESM module part of the package works as expected. I will try to do make one tomorrow.

kettanaito commented 2 years ago

It'd be great to have automated tests in different formats (CJS/ESM) that help us catch regressions regarding module format incompatibilities.

kettanaito commented 2 years ago

@weyert, I'm sorry, I think I've just messed up the commit authorship after rewording the commit. Could you please git commit --amend --author=X with your proper name + GitHub email? Thanks.

weyert commented 2 years ago

@weyert, I'm sorry, I think I've just messed up the commit authorship after rewording the commit. Could you please git commit --amend --author=X with your proper name + GitHub email? Thanks.

I think I did now but not 100% sure

weyert commented 2 years ago

It'd be great to have automated tests in different formats (CJS/ESM) that help us catch regressions regarding module format incompatibilities.

Yeah, good idea, I am not sure what the best approach is. Maybe a simple script that .mjs (for ESM) and .js (for CJS) then tries to load the package?

kettanaito commented 2 years ago

@weyert, you've set the commit author to @tapico-weyert. If it's the expected result then everything is okay!

kettanaito commented 2 months ago

Released: v0.1.0 🎉

This has been released in v0.1.0!

Make sure to always update to the latest version (npm i @mswjs/source@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.