Merge pull request #742 from wheresrhys/rhys/core-dist

chore: build both fetch-mock and core simultaneously

.circleci/config.yml

@@ -57,12 +57,14 @@ jobs:
     steps:
       - *workspace
       - run: npm run lint:ci
+      - run: npm run prettier:ci
 
   typelint:
     <<: *nodelts
     steps:
       - *workspace
       - run: npm run types:lint
+      - run: npm run types:check --noEmit=true
 
   test:
     <<: *nodelts

.husky/pre-commit

@@ -1,3 +1 @@
-#!/bin/sh
-. "$(dirname "$0")/_/husky.sh"
 npx lint-staged

.prettierignore

@@ -0,0 +1 @@
+CHANGELOG.md

docs/blog/2024-07-24-esm-and-commonjs.md

@@ -0,0 +1,26 @@
+---
+title: Publishing packages as ESM and commonjs
+slug: esm-and-commonjs
+authors:
+  - name: Rhys Evans
+    title: fetch-mock maintainer
+    url: https://www.wheresrhys.co.uk
+hide_table_of_contents: false
+---
+
+Publishing a package that is compatible with all the following is not straightforward
+
+1. A commonjs javascript project
+2. A ESM javascript project
+3. A commonjs typescript project
+4. A ESM typescript project
+
+I previously thought I'd cracked it by adding `"type": "module"` to the package.json but including a `{"type": "commonjs"}` package.json to the subdirectory that contained my commonjs built files.
+
+However [this issue](https://github.com/wheresrhys/fetch-mock/issues/726) indicated that use case 3 was not supported. [This article](https://www.sensedeep.com/blog/posts/2021/how-to-create-single-source-npm-module.html) suggested that the best solution was to build a .mjs file for ESM, a .cjs file for CJS, and leave the top level package.json without a `"type": "module"` declaration.
+
+I'm not a big fan of this as it makes it harder to fork the library or test a branch because every way of requiring it entails a build step, which is typically not carried out when requireing directly from a branch.
+
+So after mulling things over I came up with a simple solution: remove the `"type": "module"` declaration from the top level package.json and instead create a `{"type": "module"}` package.json in my srcdirectory.
+
+I thought I'd share as it's not obvious this would work - I did a fair bit of manual testing to prove it - but it's an elegant and low-build approach I've not seen publicised elsewhere.

docs/docs/@fetch-mock/core/more-routing-methods.md

@@ -5,7 +5,7 @@ sidebar_label: More routing methods
 
 # More routing methods
 
-These methods allow defining routes for common use cases while avoiding writing hard to read configuration objects. They all return the fetchMock instance, and are therefor chainable. Unless noted otherwise, each of the methods below have the same signature as `.route()`. 
+These methods allow defining routes for common use cases while avoiding writing hard to read configuration objects. They all return the fetchMock instance, and are therefor chainable. Unless noted otherwise, each of the methods below have the same signature as `.route()`.
 
 ## .catch()
 

docs/docs/@fetch-mock/core/route/matcher.md

@@ -78,7 +78,8 @@ When the `express:` keyword is used in a string matcher, it can be combined with
 }
 ```
 
-The values of express parameters are made available in the `expressParams` property when 
+The values of express parameters are made available in the `expressParams` property when
+
 - [Inspecting call history](/fetch-mock/docs/@fetch-mock/core/CallHistory#calllog-schema)
 - [Using a function to construct a response](/fetch-mock/docs/@fetch-mock/core/route/response#function)