Clarify CJS usage in v4 / CJS report with v4
drschwabe opened this issue · comments
Not sure if this is a bug because it's a little ambiguous if you are supporting CJS going forward (would be nice, but modern bundlers can typically handle both or runtimes like Bun also support CJS or ESM together out of the box, so this should not be an issue* )
So my first question is can you clarify what "with its own CJS counterpart but only for developers purpose" means as indicated in your release notes?
Second question (only seeking answer if you're supporting CJS) is there a solution to this error; I tried bundling it with an ancient Browserify build that works fine with uthml v3 but it throws an error when I try to require v4
client.js
const { html, render } = require('uhtml')
//(works in v3 but not v4)
output from Browserify build script:
Error: Can't walk dependency graph: Cannot find module 'domconstants/constants' from '/home/bob/dev/myproject/node_modules/uhtml/cjs/persistent-fragment.js'
*Using this same build script I can generally import ESM modules too ie- import { render, html } from 'uhtml'; but that throws the same error here. Haven't tried using a modern Rollup build yet but will do that soon; just thought I would report my experience so far using older bundlers/compilers like Browserify that are primarily CJS.
ps - my two cents is to do like Bun and keep longterm support for CJS if its not too much trouble
The CJS counterart is the CJS folder which is published as dual module as pretty much 100% of my stuff ... nobody ever had issues with that but ... browserify missed the note about imports defined in the package.json while rollup and all others should work out of the box and just fine.
Stop using browserify would be my hint, but there's nothing I can do, or want to do, to support legacy bundlers ... ESM is the default and de-facto standard for JS so ... it's up to you to decide to never catch up and be stuck forever with legacy but it cannot be every module developer burden to satisfy this requirement.
Before I was publishing an artifact via rollup that was landing on the global context and that is what changed here ... the rest is fine, as it's always been.