endojs
Tracking issue for getting 3rd party packages more SES friendly
Fear that tape overrode Function.prototype.apply cleared by @ljharb at https://github.com/Agoric/SES-shim/issues/474
Good news about JSS and enzyme https://github.com/Agoric/agoric-sdk/pull/2321#issuecomment-777099286
Issue filed with vega https://github.com/vega/vega/issues/3075
https://github.com/Agoric/agoric-sdk/pull/2575 patches problems with vega and d3, including the vega problem mentioned above reported at https://github.com/vega/vega/issues/3075
Still need to report problem to d3
Still need to report https://github.com/Agoric/agoric-sdk/issues/2324 to node, that it gets confused if Object.prototype.constructor is an accessor property. Attn @bmeck
https://github.com/vega/vega/pull/3109 would no longer fix https://github.com/vega/vega/issues/3075
We need to file a bug against https://github.com/feross/buffer that their code is incompat with frozen primordials, causing https://github.com/Agoric/agoric-sdk/issues/2663
https://github.com/vega/vega/pull/3109 has been merged and https://github.com/vega/vega/issues/3075 closed. Thanks @jheer !
https://github.com/endojs/endo/issues/621 reports that regenerator-runtime overrides Object.prototype.constructor by assignment. We should file a bug against it. In the meantime we will probably patch it.
More on the regenerator problems https://github.com/facebook/regenerator/issues/410 https://github.com/facebook/regenerator/issues/411
luxon assigns to toLocaleString on an obj :crying_cat_face: https://npmfs.com/package/luxon/1.24.1/build/cjs-browser/luxon.js#L7081
however they are using class syntax in their src https://npmfs.com/package/luxon/1.26.0/src/datetime.js#L1503
so likely a result of using babel https://github.com/moment/luxon/blob/91c5f87e7eed66f09165419455f47809990bd4f8/tasks/build.js#L4
and could be fixed there
@formatjs/intl-utils src also has the same export hasOwnProperty that ends up as a conflicting exports.hasOwnProperty assignment. may be tsc performing the esm->cjs transform
We need to file a bug on React so that https://github.com/endojs/endo/pull/642 is no longer needed to avoid https://github.com/Agoric/dapp-token-economy/issues/159 . If we modify React to fix that bug, we should push that PR upstream.
https://github.com/endojs/endo/issues/612 is another conflict with react. Attn @rbuckton @ljharb @AidenRourke
Note that @AidenRourke at #642 says
If I just have an html file that imports ses and calls lockdown there is no error
We do that as well before any of the rest of react. The need for this is yet another problem with react we need to file.
React uses reflect.metadata?
That was within the symptoms we were seeing as well. Specifically, we saw an attempt to add a Reflect."@decorate" method. (Not sure I'm getting the name right)
As far as I can tell, react doesn't use reflect-metadata or Reflect.decorate. I'd need more to go on to be any help.
Hey all, the error I get when trying to use window.lockdown() with react is
index.js:1 failed to delete intrinsics.Array.@wry/context:Slot of type function: (TypeError#1)
@AidenRourke is this only react or some additional react packages
heres what directly uses @wry/context
was not familiar with wry :eyes: https://github.com/benjamn/wryware
A collection of packages that are probably a little too clever. Use at your own wrisk.
perhaps too clever, yes
https://github.com/benjamn/wryware/blob/569d7a6294b77aa9e71d7c7709344aca7cbb75a1/packages/context/src/slot.ts#L126-L135
@AidenRourke this global pollution should gracefully fail if you run lockdown before your dependencies that include @wry/context
@kumavis btw I think what you're doing with lavamoat is super cool.
To answer your question, I experienced the error even with a stock create react app.
Last time I tried to put the ses import and subsequent call to lockdown in the head of the index.html file, I still got the error.
Any chance you have NODE_OPTIONS set?
We don't. I grepped and the only mention of NODE_OPTIONS anywhere in our code is in an esm-*.patch file: https://github.com/Agoric/agoric-sdk/blob/master/patches/esm%2B3.2.25.patch
@erights meaning, you can reproduce this issue with a stock CRA, with no NODE_OPTIONS set?
@erights meaning, you can reproduce this issue with a stock CRA, with no NODE_OPTIONS set?
That's correct.
See https://github.com/microsoft/TypeScript/issues/43463 https://github.com/microsoft/TypeScript/issues/43450 https://github.com/mrkmg/node-external-editor/issues/25
Re https://github.com/endojs/endo/issues/576#issuecomment-809131839 and https://github.com/endojs/endo/issues/612
We need to file a bug against https://github.com/benjamn/wryware/blob/569d7a6294b77aa9e71d7c7709344aca7cbb75a1/packages/context/src/slot.ts#L126-L135 .
Re https://github.com/vega/vega/pull/3109#issuecomment-792590332
we need to file a bug against rollup for the way it generates the exports object by assignment.
In https://github.com/Agoric/documentation/pull/579#discussion_r762365040 @erights acknowledges that https://github.com/endojs/endo/wiki also tracks 3rd party package issues and says we should consolidate.
My preference would be to
- use a separate issue for each compatibility issue
- it's OK for an issue to start out fuzzy, but in due course it should get a clear scope that can be finished; this issue shows no sign of ever being done.
- use a github label (perhaps npm-compat) to facilitate finding all of them
- use a wiki page to summarize common problems and solutions with a pointer to the labelled issues
Hm... that assumes the resolution to the issues is changes to ses. But I suppose as often as not we're changing the other packages to work with SES. A wiki page makes for a better index than a label, in that case.
OTOH: changes to wiki pages don't result in notifications the way changes to issues do. hm.
- immer (writes mapInstance.set) https://github.com/immerjs/immer/pull/914/
- web3-core-method (writes functionInstance.call) https://github.com/ChainSafe/web3.js/pull/4918
- gun (writes so many utility functions) https://github.com/amark/gun/pull/1217
- error-polyfill (try to polyfill Error.captureStackTrace and Error.getStackTrace) https://github.com/inf3rno/error-polyfill/pull/38/
Following packages bundles their own old version of regenerator-runtime (0.11.* or older) which is not compatible with lockdown:
- @ceramicnetwork/rpc-transport
- @ceramicstudio/idx
- @uniswap/v3-sdk
- key-did-provider-ed25519
- rpc-utils (before 0.6.0)
