Closed cre8 closed 10 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
165de35
) 85.50% compared to head (59ee796
) 85.50%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
In case of testing: I am not sure if we can write tests for a CJS and a ESM case. But it would allow to use the libraires in frameworks like nestjs that are focussed on CJS (you can compile to ESM, but then some features are missing).
Even when in some years ESM dominates the backend market, we do not need to support both approaches (unless we see a big drawback with this approach)
One thing that is not covered in the current update is the type-check. This has to be done with tsc. I excluded it since this gave some errors according to other libraries.
So the pro argument of this is that we have CJS and ESM. The downside is more complexity since we are using TSC (for type checking and type generation) and es build (for converting to JS and bundling for CJS). The argument "compiles faster" is not really there, since even when using it in other dependencies you need to generate the types with tsc (I haven't measured the times tsc need for compiling + type generation and only type generation).
Writing these lines I am not 100% if this is a feature worth of trying. Maybe esbuild is good for applications where you don't care about available types, you just want a bundled pack of JS files...
I don't mean unit/integration testing necessarily. I mean, do you have a project that fails to build/work using the current ESM build where we could test the new build setup?
We can publish these changes under the @unstable
distTag before merging them into next
so there would be a npmjs ready artifact that can be used for testing.
I like the unstable option. I can setup a nestjs project with then openapi integration. There I always failed to use ESM
I updated all packages to esbuild and the build command passes. However I removed also the '.js' extensions for the import paths because I thought you do not need them (and there should be a solution for this). WIth the flag node --experimental-specifier-resolution=node ../cli/bin/veramo.js dev extract-api
I was able to call it, but then I am getting this error:
packages/core extract-api: file:///C:/Users/mollik/Projects/veramo/packages/core-types/build/types/ICredentialStatusManager.js:1
packages/core extract-api: import { DIDDocument, DIDResolutionOptions, DIDResolutionResult } from "did-resolver";
packages/core extract-api: ^^^^^^^^^^^
packages/core extract-api: SyntaxError: The requested module 'did-resolver' does not provide an export named 'DIDDocument'
packages/core extract-api: at ModuleJob._instantiate (node:internal/modules/esm/module_job:124:21)
packages/core extract-api: at async ModuleJob.run (node:internal/modules/esm/module_job:190:5)
packages/core extract-api: Node.js v18.17.0
Before reverting the commit with the '.js transformation', I just wanted to check if someone of you has an easy solution how we can deal with it (this explains the +200 file changes ;))
I continued the work in a new PR: https://github.com/decentralized-identity/veramo/pull/1328 since this one had to much files changed
What issue is this PR fixing
fixes: #1321
The utils package is build with esbuild. However the current task fails since the build task in the
package.json
file with"build": "node esbuild.js && tsc --emitDeclarationOnly",
will not exectute the tsc command. Even when putting the command in a dedicated job like"types": "tsc --emitDeclarationOnly",
it fails. However calling it directly in the folder (and not via the package.json), it works. To get all build work for now:npm run build
tsc --emitDeclarationOnly
Update: when packing the
package.json
executable the task works (withchmod +x package.json
)What is being changed
It will publish the packages in ESM and commonjs so all developers are happy :)
Quality
Check all that apply:
pnpm i
,pnpm build
,pnpm test
,pnpm test:browser
locally.Details
If applicable, add screen captures, error messages or stack traces to help explain your problem.