-
-
Notifications
You must be signed in to change notification settings - Fork 228
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
continuing esmification #288
Conversation
56b5556
to
ef3250e
Compare
Fixed the conflicts from the original PR and switched the tests over to import, but getting this error:
|
Ah dammit ok, this is stuck on directory imports being used everywhere and it's not just a case of shoving a .js which is easy enough. import { abs, url as _url } from "../../utils/path";
import { abs, url as _url } from "../../utils/path.js"; That works, but wtf do I do with |
Is there a reason that wouldn't be Also you shouldn't need to put |
35a4fae
to
fba9aca
Compare
still getting issues, looks like export default { /** * Returns the current working directory (in Node) or the current page URL (in browsers). * * @returns {string} */ cwd () { does not actually make import { cwd } available?
89589f9
to
802e5f9
Compare
@wparad I don't know what I'm doing, which is a lot of the issue. I have run around adding lots of .js to everything which was labourious and probably incomplete, so if there's a way to automatically pull in .js that'll be lovely. Let's do that. Can you show me how? A bigger issue now is:
The approach being used in that library is this:
and im not sure thats the right way to name exports to be used like this?
|
For the second one it is For the first one, I assume it's a babel or eslint issue more than it is anything else, but I would need to see the actual error to suggest a fiix. |
802e5f9
to
2b00735
Compare
Thanks @wparad. I've brought in the
Looks like import needs a file extension.
https://nodejs.org/api/esm.html#esm_import_statements I am fumbling around in the dark trying to finish up other peoples pull requests here and I really don't have time for it. Can somebody please help me get this pull request working, by running |
Calling on @aerialist7 to help get this done, or anyone. |
Okay so it seems resolving without the extension is still experimental. If we want to do it anyway we need something like babel, and don't we need babel anyway if we want to provide support for everyone using the library that isn't using esm? Or is the plan to force everyone using the library to convert to es modules if they want to use it? (Just a quick reference on cjs usage) |
Oh I forgot I wrapped this library not long ago to specifically add cjs/esm/browser support, there are some minor changes in this repo which might offer some inspiration into supporting the babelify: https://github.com/Rhosys/openapi-resolver.js |
I started playing around with this branch. If no one beats me to it, I can try to get something out this week. I don't think we'll need a separate build step. See: #290 (comment) |
Hi guys, sorry, but I have no time now to continue esmification process. |
Hey all, I've tried to finish this in a different PR since I wanted to make sure that CI tests were passing first, since they haven't been passing for a while now: This PR fixes tests to provide a baseline: This PR converts this project to ES modules: What I haven't done is provide dual CommonJS/ES module support as this thread has discussed. It would be possible similar to #290 (comment) - just have to bundle up the ESM files and reference from package.json. |
#295 now implements dual CommonJS/ES module support. |
Based on #268