Closed mike-marcacci closed 2 years ago
I reckon publish the fix in https://github.com/mike-marcacci/fs-capacitor/pull/76 now as it is with pure ESM, then if we decide to add support for CJS consumers it can happen in a following version.
@mike-marcacci are you able to publish the changes, or is there more work to be done?
My apologies – I meant to publish this after your last comment. I just published v8.0.0. I'm going to go ahead and close this issue as well, and we can reopen this if this need comes back up.
The v8.0.0 changelog entry and GitHub release descriptions don't mention the fixes:
@mike-marcacci , is there any common js support?
I am trying to use fs-capacitor
in the following way and I am getting this weird error now.
import { ReadStream, ReadStreamOptions, WriteStream } from 'fs-capacitor'
Error [ERR_REQUIRE_ESM]: require() of ES Module .../node_modules/fs-capacitor/dist/index.js from .../server.ts not supported.
Instead change the require of index.js in .../server.ts to a dynamic import() which is available in all CommonJS modules.
...
I am using ts-node/ts-node-dev
for the development and here is the tsconfig.json
file.
{
"compilerOptions": {
"module": "commonjs",
"incremental": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"declaration": true,
"target": "ES2018",
"noImplicitAny": true,
"moduleResolution": "node",
"sourceMap": true,
"skipLibCheck": true,
"outDir": "dist",
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"strict": true,
"resolveJsonModule": true,
"removeComments": true,
"forceConsistentCasingInFileNames": true,
"baseUrl": ".",
"rootDir": "."
},
"include": ["src"],
"exclude": ["node_modules/**", "dist"]
}
I am also using "module": "commonjs"
in package.json
.
This library is currently only published as an ES module without a CommonJS counterpart. As a zero-dependency package, it had appeared less susceptible to the whiplash in guidance for migration to ES modules, and my hope was that doing so might enable consuming packages to leverage the benefits of this newer approach.
However, I want to make sure that this continues to follow best practice. I have a couple changes ready for release as
v8.0.0
(most notably #76) but want to give @jaydenseric the chance to figure out if there is anything this library could do to improve the ability to be used here.I'm not fully up-to-date on the ever-changing recommendations for how to designate the various types of package exports in node, so I wanted to open a conversation for anyone with insight or a strong preferences.