Skip to content

Conversation

@sigma-andex
Copy link
Contributor

@sigma-andex sigma-andex commented Feb 11, 2022

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:

  • Added a file to CHANGELOG.d for this PR (see CHANGELOG.d/README.md)
  • Added myself to CONTRIBUTORS.md (if this is my first contribution)
  • Linked any existing issues or proposals that this pull request should close
  • Updated or added relevant documentation
  • Added a test for the contribution (if applicable)

kl0tl added 30 commits April 22, 2020 23:25
ES modules are already parsed in strict mode.
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.
@JordanMartinez
Copy link
Contributor

CI is failing because I deleted the es-modules branch for the purescript-lists repo since it doesn't have any FFI. I'll push a commit that reverts it back to 6.0.0 after verifying that the resolutions field doesn't need to also be updated.

@JordanMartinez
Copy link
Contributor

For those not watching the working-group-purescript-es/purescript repo, @rhendric opened a PR addressing his concern about the extra IIFEs and his concern about the Pure constructor being separate from the Comment constructor, which hinders optimization passes later, in working-group-purescript-es#15

His comment about the .cjs file extension was not addressed in the above PR.

@JordanMartinez
Copy link
Contributor

IIUC, this imperfectly-named variable is the output of the bundler, which is a CommonJS module, and we seem to be sticking to the convention that .js means ES module and .cjs means CommonJS module.

Since we'll be dropping purs bundle, I don't think this issue needs to be dealt with.

@rhendric
Copy link
Member

Since we'll be dropping purs bundle, I don't think this issue needs to be dealt with.

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. 😄

Copy link
Member

@rhendric rhendric left a 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?

@natefaubion
Copy link
Contributor

@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:

  • Fix up it's static server to serve individual modules.
  • Remove the browser REPL altogether.

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.

@rhendric
Copy link
Member

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.

@natefaubion
Copy link
Contributor

natefaubion commented Feb 25, 2022

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.

@rhendric
Copy link
Member

Oh, ignore me then!

@JordanMartinez
Copy link
Contributor

v0.14.7 has been released.

@JordanMartinez JordanMartinez merged commit ff68b93 into purescript:master Feb 27, 2022
@JordanMartinez
Copy link
Contributor

JordanMartinez commented Feb 27, 2022

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.

@rhendric
Copy link
Member

#4241 is approved?

@JordanMartinez
Copy link
Contributor

Oh, it's not yet. Sorry about that, and thanks for pointing that out.

@rhendric rhendric mentioned this pull request Feb 27, 2022
@rhendric
Copy link
Member

Is that it for this round of merges? I'll start updating my long PRs if so.

@JordanMartinez
Copy link
Contributor

I'm trying to get #4241 in. Then I'd like to merge #4248. After that, yeah.

@rhendric
Copy link
Member

Sounds good, thanks, and thanks for all the hard work.

@JordanMartinez
Copy link
Contributor

Just FYI. https://github.com/purescript/purescript/actions/runs/1904795691 failed to build master because of a lint error. I merged #4240 (which built fine) and then merged #4239 (which didn't rebuild after #4240 was merged). So, maybe that had something to do with it?

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.

@rhendric
Copy link
Member

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.

@JordanMartinez
Copy link
Contributor

I'm trying to get #4241 in. Then I'd like to merge #4248. After that, yeah.

Since #4241 will need a more in-depth review and may possibly require us to merge a PR dropping purs bundle before it'll build, I'd like to merge #4249 (can I get an approval once CI builds?) to fix CI, and then merge #4248. After that, we'll be done for this round of PRs, I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants