Closed CWSpear closed 2 years ago
It's also probably worth having automated tests that test CJS code, since that's the most common way people are probably going to use the code as of right now.
looks like, I can't find a a import solution which work on esm and cjs at the same time.
Well, this is what I'm doing to get it worker for now:
in Dockerfile
:
RUN node ./fixes.js
fixes.js
:
const path = require('path');
const fs = require('fs');
const metadataStoragePath = path.join(__dirname, 'node_modules/discordx/build/cjs/logic/metadatas/MetadataStorage.js');
const metadataStorageContents = fs.readFileSync(metadataStoragePath, { encoding: 'utf8' });
const newMetadataStorageContents = metadataStorageContents.replace(`"file://" + `, '');
fs.writeFileSync(metadataStoragePath, newMetadataStorageContents, { encoding: 'utf8' });
The import
is okay--that's not esm
-specific. It's trying to load a path file://
at the start that's killing it.
well, I looked for every possible solution, I don't think their is one for this issue.
It's hacky, but #234 gives you a way to programmatically know if you're in CJS. It causes CJS-specific test that was failing with this same error to pass.
npm link
ed it to my local project, and it was able to build and run.
this issue is not related to this lib, it's related to glob. glob lib is written in esm and esm support file protocol only, hence this should be a issue with glob only to provide absolute paths
No... your CJS code can't support glob's CJS code. That sounds like it's definitely something on your end. glob
shouldn't need to support ESM so your CJS version can run in a CJS context.
Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'
dynamic imports on node.js with esm, should have file protocol.
Yeah, and in the ESM version, it still will. It only doesn't add the file://
in the CJS version.
Yeah, and in the ESM version, it still will. It only doesn't add the
file://
in the CJS version.
yes, but the issue is this lib does not know when to add this prefix or not. This can be fixed with postfix script, just like in your PR. but for now, we are dropping the classes field with breaking change. so this will be not part of this package anymore.
the reason, why I choose to remove is, we are now maintaining codebase for cjs and esm at the same time. critical issues that can impact this lib in future, should resolved with better solutions. which typescript add in node12 but, we can not expect everyone to use node12 atm.
I'm confused... what does Node 12 have to do with anything? This library only supports Node 16+, so we can pretty safely expect everyone to use a version higher than Node 12.
What did TypeScript add in Node 12 that helps here?
I'm confused... what does Node 12 have to do with anything? This library only supports Node 16+, so we can pretty safely expect everyone to use a version higher than Node 12.
What does TypeScript add that helps here?
That doesn't make it work with import('file://...')
paths. The import
is already left alone and working in in the CJS code. Unfortunately, this change isn't really relevant here. :(
That doesn't make it work with
import('file://...')
paths. Theimport
is already left alone and working in in the CJS code. Unfortunately, this change isn't really relevant here. :(
indeed, that is why decided to remove the field instead.
You can't satisfy pure esm and cjs at the same time unless you use ts4.5
This is why projects like mode fetch went pure esm and can't be used with cjs unless you use version 2.x
You can't satisfy pure esm and cjs at the same time unless you use ts4.5
This is why projects like mode fetch went pure esm and can't be used with cjs unless you use version 2.x
this can't be resolved with ts4.5 as well
since the classes is removed, devs can use @discordx/importer
Example usage
import { importx } from "@discordx/importer";
await importx([`${__dirname}/commands/**.js`]);
future development regarding this will be done in importer package alone.
since the classes is removed, devs can use @discordx/importer
Example usage
import { importx } from "@discordx/importer"; await importx([`${__dirname}/commands/**.js`]);
future development regarding this will be done in importer package alone.
@CWSpear I request you to please do tests with importer
@CWSpear and use importer in your cjs project, we can't release any update untl djs 13.4 released.
Issue will closed after ts4.5
update: issue will be closed after djs v13.4, meantime use importer to resolve this issue in your project.
Example for importer usage
import { resolve } from "@discordx/importer";
const commands = resolve([
path.join(__dirname, "{events,commands}", "**/*.{ts,js}"),
]);
commands.forEach(require);
The importer is now have bunch of features that will make job easier then our deprecated classes field.
What happened?
The code assumes ESM and prepends
file://
to file paths before trying toimport
them. This does not work in CJS.Reproduction
Trying to run the above code with the CJS will compile and run, but at runtime,
MetadataStorage.ts
will try to load it by prependingfile://
to the path name, and so it crashes.We'll need to find a way to dynamically handle this... or probably just make the end user handle it and they'll have to prepend
file://
.Sorry I didn't catch this last night... because of the
discordjs/voice
issue, I couldn't even get it to build to try and test further.Package
discordx
Version
Stable
Relevant log output
Code of Conduct