Closed laughedelic closed 2 years ago
This is because a parent dependency is doing something like:
import uuid from 'uuid';
which is importing the default export.
This module is being loaded from https://jspm.dev/npm:uuid@8!cjs, where you can see it exports from https://jspm.dev/npm:uuid@8.3.2!cjs. Looking at that file in turn we can see that it is an ES module without any default export.
The !cjs
in the URL means that it is supposed to pick the "require"
variant of the "exports" condition.
The exports definition of uuid is in https://unpkg.com/uuid@8.3.2/package.json, and shows the exports field:
"exports": {
".": {
"node": {
"module": "./dist/esm-node/index.js",
"require": "./dist/index.js",
"import": "./wrapper.mjs"
},
"default": "./dist/esm-browser/index.js"
},
"./package.json": "./package.json"
},
What this means is that the "require" - or the CommonJS version with the default export, is only loaded in Node.js. As a result jspm is loading the "default" export above which corresponds to an ES module which does not have a default export.
So this is a misconfiguration in the UUID package.
I'm not sure "fixing" uuid will make the package work with deno. UUID browser entry point uses webcrypto which is not supported by deno. https://github.com/jspm/project/issues/93 So the problem is that jspm does not bundle for node.
Agreed web crypto would need to be polyfilled as well for the Deno support, but that doesn't change the nature of the browser / node API discontinuity in play which will still affect browser users.
@guybedford Thanks for the context! Is there anything I can do to help with fixing this or can I temporarily work around this issue in my code? Also, I'm not sure what you're saying about web crypto. Is it some node dependency that has to be substituted because it doesn't work on Deno?
@laughedelic standard procedure here is to ask the person filing the bug to submit a PR to the original repo. It sounds like @TrySound might be on it, but otherwise I would suggest creating a PR extending the exports field to include the correct entry point for uuid.
If this PR upstreaming process fails or hits a road block then we do have the JSPM overrides service at https://github.com/jspm/overrides to merge this package.json adjustment as an explicit override configuration but that should only be considered a last resort if the standard upstreaming process fails as it effectively creates a fork.
For local workarounds you should be able to apply an import map to remap the UUID entry point appropriately, using a configuration something like:
<script type="importmap">
{
"imports": {
"https://jspm.dev/npm:uuid@8!cjs": "https://unpkg.com/uuid@8.3.2/dist/index.js"
}
}
</script>
I can't personally drive all these changes though so have to rely on maintainers / users to be receptive to the process here. Wil work on better communicating this process.
Thanks for the guidance! I will try to submit a fix to uuid repo (UPD: https://github.com/uuidjs/uuid/pull/563).
I also tried using import map, but hit the
error: Unmapped bare specifier "crypto"
which, I guess, was expected. I tried also adding "crypto": "https://jspm.dev/@peculiar/webcrypto"
to the import map, but that gives me
error: Import 'https://jspm.dev/npm:pvutils@latest!cjs' failed: 404 Not Found
at https://jspm.dev/npm:asn1js@2!cjs:1:0
And if I try to point it to a concrete version instead of latest: "https://jspm.dev/npm:pvutils@latest!cjs": "https://jspm.dev/npm:pvutils@1.0.17!cjs"
, it gives me the original
error: Uncaught SyntaxError: The requested module '/npm:uuid@8!cjs' does not provide an export named 'default'
import _uuid from '/npm:uuid@8!cjs';
~~~~~
at <anonymous> (https://jspm.dev/npm:teeny-request@7.0.1!cjs:3:8)
@laughedelic nice to see you digging into it here further and thanks for sharing and posting that PR. Just looks like you need to fix the trailing comma for the CI.
And if I try to point it to a concrete version instead of latest: "https://jspm.dev/npm:pvutils@latest!cjs": "https://jspm.dev/npm:pvutils@1.0.17!cjs", it gives me the original
This actually sounds to me like a bug in Deno import maps support as that module shouldn't be loaded at all if it is being explicitly mapped. They've been working a bit on the implementation recently - make sure you are using the latest version.
Not sure if you saw, but the latest CDN for import maps was just released at https://jspm.org/import-map-cdn. You might have an easier time with the import map customization with the generator tool there against the ga.jspm.io
import maps CDN.
Trying to import @google-cloud/bigquery (from Deno, but also in the sandbox)
results in
Could you explain what this error means and if it's possible to work around it?