-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[email protected]
is incorrectly presenting as a transpiled ES Module
#233
Comments
Thanks for a detailed bug report. Could you please check how does the branch https://github.com/Starcounter-Jack/JSON-Patch/tree/use-ES6-modules work for you? To install a GitHub branch as NPM package:
Or add this to
And then follow the instruction in README.md to import: |
Hi @warpech, this branch is causing SyntaxErrors in our tests:
I see that in your Stepping back a bit... in my view, the problem isn't with the module syntax (import/export vs The root of the issue is the combination of (a) the shape of object that is exported from the module and (b) the |
To me it seems like a weird behavior of typescript compiler microsoft/TypeScript#14351 |
Issue was introduced by updating typescript at 54911b2#diff-529047924cdb0e5562a8de34628a855dR111 |
the version that was not adding `Object.defineProperty(exports, "__esModule", { value: true });` Therefore, resulting in module transpilable to one with unintended default export. Fixes backward compatibility and #233
It occurred to be related to backward incompatible change related to undocumented default export. We will revert this breaking change, and release a new version to support Swagger among many other projects that are currently using default export as a map of all named ones. However in README we would still recommend using named imports. |
Thank you @shockey for your help in resolving this. We have fixed this regression in a patch release 2.2.1 and added exernal API usage tests for this to never fail again (PR #236) Anyway we will keep recommending using named imports in README.md, because they are less error prone. See https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/ for a nice list of reasons. |
[email protected]
is breaking builds in Swagger Client (see swagger-api/swagger-js#1460).Current behavior
The problem is that
fast-json-patch
is combining the__esModule
hint with an exports object that follows the CJS exports pattern.2.2.0 is setting an non-enumerable
__esModule
hint property that wasn't present before:➜ node -e 'const fjp = require("fast-json-patch"); const util = require("util"); console.log(util.inspect(fjp, { showHidden: true, depth: 0 }));' { [__esModule]: true, applyOperation: [Object], applyPatch: [Object], applyReducer: [Object], getValueByPointer: [Object], validate: [Object], validator: [Object], JsonPatchError: [Object], deepClone: [Object], escapePathComponent: [Object], unescapePathComponent: [Object], unobserve: [Object], observe: [Object], generate: [Object], compare: [Object] }
This property is used in transpilers and module loaders to handle interoperability between CJS modules and ESM modules represented as JavaScript objects -- specifically, CJS modules need to be wrapped inside another object's
default
property. More info here.All of this means that when I use import syntax to use
fast-json-patch
in my Babel-enabled project:...Babel translates my import to:
...which means at runtime, my code will see
__esModule: true
infast-json-patch
and therefore not wrap the exported result from it in adefault
key:Expected behavior
fast-json-patch
should either be not setting__esModule
(which was the previous behavior), or should be exporting an object that matches ESM syntax, e.g.{ __esModule: true, default: { applyOperation: [Object], ... } }
.The text was updated successfully, but these errors were encountered: