Different packages in different branches

[onlywei]

Hello,

Thanks so much for releasing json-logic-engine-slim!

I noticed that the way this git repo is set up is that the slim version is in a different branch. What do you think about converting the repo to workspaces so that each package has its own folder? That seems to be the pattern for most open source projects these days.

packages/
  json-logic-engine/
  json-logic-engine-slim/
package.json

If that sounds appealing to you I can try and make a PR.

[TotalTechGeek]

The main reason I branched was to make it easier to cherry-pick changes & quickly iterate on slimming it down.

I'm working in the background on trying to figure out how to best consolidate both projects into a single branch, without resorting to weird metaprogramming tricks (stripping out & rewrite code).

I'm working on reorganizing the codebase a bit to make this easier to pull off, but inevitably, I want to essentially produce builds under the same package, so one could do:

import { LogicEngine } from 'json-logic-engine/slim' 

But it could be a minute before I get to a place where I'm happy with it. I find that the other branch is a bit easier for me to maintain for now.

[onlywei]

I had Claude Opus 4.5 analyze the repo based on what you said, and here is a plan it came up with. Let me know if this aligns with what you are thinking or not. I can have Claude Code just do it all and make a PR.

Goal

Enable usage like:

// Full featured (current behavior)
import { LogicEngine, Compiler } from 'json-logic-engine'

// Slim version (no compiler/optimizer)
import { LogicEngine } from 'json-logic-engine/slim'

---

Implementation Plan

1. Create a new slim.js entry point

This file would export only the core classes without the compiler and optimizer:

• LogicEngine
• AsyncLogicEngine
• defaultMethods
• Constants

The existing index.js continues to export everything (including Compiler, optimizers, asLogic, etc.).

2. Add subpath exports to package.json

"exports": {
  ".": {
    "import": "./dist/esm/index.js",
    "require": "./dist/cjs/index.js",
    "types": "./index.d.ts"
  },
  "./slim": {
    "import": "./dist/esm/slim.js",
    "require": "./dist/cjs/slim.js",
    "types": "./slim.d.ts"
  }
}

3. Update the build configuration

Add rollup commands to build the slim entry point alongside the main one:

rollup slim.js --file dist/cjs/slim.js --format cjs --exports named
rollup slim.js --file dist/esm/slim.js --format esm

(Or migrate to a rollup.config.js for cleaner multi-entry builds)

4. Generate TypeScript declarations for the slim export

---

Approach Options

There are a few ways to handle the "slim" variant:

Approach	Description	Trade-offs
Conditional exports	Same codebase, slim.js just doesn't export certain modules	Simple; relies on tree-shaking to reduce bundle size
Separate source trees	Maintain src/slim/ and src/full/ with shared code	Clean separation; risk of code duplication
Build-time stripping	Use build flags to exclude modules entirely	Optimal bundle sizes; more complex build

I'd suggest starting with conditional exports since it's the simplest and modern bundlers handle tree-shaking well. If bundle size becomes a concern, we can optimize further later.

---

Benefits

• Single repo, single package, no more branch juggling
• Users can choose their bundle size vs. feature trade-off
• Easier to maintain and release
• Cherry-picking between variants is no longer needed

---

Let me know if this approach aligns with what you had in mind, or if there are other considerations I should factor in.