-
Notifications
You must be signed in to change notification settings - Fork 571
Support es modules #4232
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
Support es modules #4232
Conversation
ES modules are already parsed in strict mode.
This reverts commit 7f0c07e.
Node.js loads JavaScript files with a .js extension as CommonJS modules unless they're within a directory with a `"type": "module"` package.json, in which case it loads them as ES modules.
Node.js ignores the package.json file of the output directory otherwise and loads .js files as CommonJS modules.
Node.js allows ES modules to import CommonJS modules by providing the module.exports object as their default export and named exports for statically discoverable properties of the module.exports object.
This has an unpleasant consequence for foreign imports: CommonJS exports named `default` are only available as the default property of their default export so a `default :: String` identifier imported from a CommonJS foreign module would actually have type `{ default :: String }`!
The require function and the exports object are not available in ES modules on Node.js.
This reverts commit 4976eee.
|
CI is failing because I deleted the |
|
For those not watching the His comment about the |
Since we'll be dropping |
I was possibly unclear; I was justifying the change, not saying that it's an issue that needs to be resolved. Nets out to the same result as your conclusion though. 😄 |
rhendric
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (naturally, now that I've gotten my hands into it), but what's going on with this thread about the browser REPL backend?
|
@rhendric The browser REPL is effectively broken because it relies on purs bundle. Since we are removing purs bundle in a follow up we need to either decide:
I'm personally in favor of the second option, because I'm not aware of anyone taking advantage of it, and I find the experience of try-purescript to be so much better for testing things in the browser (try-purescript will need to be updated at some point too). In our discussions, no one expressed interest in maintaining this feature. However a consensus will need to be reached among the core team as a whole. If others on the team are interested in using and maintaining it, that's fine. |
|
I've never used this feature either (and would personally be fine with removing it if due diligence is done), but my understanding is that it's not a REPL in the browser; it's a browser-hosted backend for the console REPL. In a sense it's the inverse of Try PureScript, which is a server-hosted backend with a browser frontend. I think it's potentially uniquely useful for people doing frontend development in PureScript and who want to test some foreign JS integration not supported in Node.js. |
The browser repl just pushes evaluation to the browser. In that sense, it's not different from try purescript, which also evaluates in the browser (it does not evaluate on the backend), except you also have an editor right there as well. |
|
Oh, ignore me then! |
|
|
|
I merged the following PRs in the following order to see what merge conflicts might arise. All merge conflicts are minor:
I'll be merging these PRs in the above order once CI passes since all of them are already approved. |
|
#4241 is approved? |
|
Oh, it's not yet. Sorry about that, and thanks for pointing that out. |
|
Is that it for this round of merges? I'll start updating my long PRs if so. |
|
Sounds good, thanks, and thanks for all the hard work. |
|
Just FYI. https://github.com/purescript/purescript/actions/runs/1904795691 failed to build Also, if we're spamming this PR and should move future conversations to another issue, could someone open a new issue? I'm responding here because most of the people involved are already subscribed to this thread. |
|
Yeah, the error is from Weeder; what happened is that with both of those PRs merged, we got rid of the last usage of the function that emits warnings during parsing! We can add it to the list of roots in weeder.dhall and/or just merge #4241, which uses it again. |
Since #4241 will need a more in-depth review and may possibly require us to merge a PR dropping |
Description of the change
This PR adds es modules support to purescript. It is the rebased pr #3791 from the es modules working group with fixed purity annotations. Solves #3613.
Checklist: