diff --git a/blog/404.html b/blog/404.html index 80da13421..55f1f6d40 100644 --- a/blog/404.html +++ b/blog/404.html @@ -14,7 +14,7 @@

404 Page Not Found

- + \ No newline at end of file diff --git a/blog/feed.rss b/blog/feed.rss index ab71ea44a..0474ded67 100644 --- a/blog/feed.rss +++ b/blog/feed.rss @@ -4,7 +4,7 @@ Sandtracks https://melange.re/blog The official blog for the Melange project - Fri, 24 May 2024 16:45:19 GMT + Mon, 10 Jun 2024 13:20:32 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en diff --git a/blog/hashmap.json b/blog/hashmap.json index 9f5b6ea28..fba5f38f7 100644 --- a/blog/hashmap.json +++ b/blog/hashmap.json @@ -1 +1 @@ -{"posts_introducing-melange-20.md":"QfX6_eze","index.md":"xkUv1qQq","posts_dune-universal-libraries-preview.md":"tCsi-mz5","posts_whats-next-for-melange.md":"Afjjed8t","posts_announcing-melange-3.md":"jIg91yLx","posts_whats-2024-brought-to-melange-so-far.md":"vw5SFBcR","posts_melange-4-is-here.md":"HWp7dt5h","posts_the-rest-of-2023-in-melange.md":"M7RgHIEQ"} +{"posts_the-rest-of-2023-in-melange.md":"M7RgHIEQ","posts_announcing-melange-3.md":"jIg91yLx","posts_whats-2024-brought-to-melange-so-far.md":"vw5SFBcR","posts_melange-4-is-here.md":"HWp7dt5h","posts_introducing-melange-20.md":"QfX6_eze","posts_whats-next-for-melange.md":"Afjjed8t","posts_dune-universal-libraries-preview.md":"tCsi-mz5","index.md":"xkUv1qQq"} diff --git a/blog/index.html b/blog/index.html index f33068035..4486a6366 100644 --- a/blog/index.html +++ b/blog/index.html @@ -63,7 +63,7 @@

But we're not done yet: there's more in slate for the next quarter. I'll tell you what we're looking to achieve in Q3 2023.

Read more →
- + \ No newline at end of file diff --git a/blog/posts/announcing-melange-3.html b/blog/posts/announcing-melange-3.html index 5174a1b1e..83f86c104 100644 --- a/blog/posts/announcing-melange-3.html +++ b/blog/posts/announcing-melange-3.html @@ -17,7 +17,7 @@
Published on

Announcing Melange 3

Authors

We are excited to announce the release of Melange 3, the latest version of our backend for the OCaml compiler that emits JavaScript.

This new version comes packed with significant changes, improvements, and a few necessary removals to ensure a more streamlined and efficient experience for our users. This new version is both leaner and more robust. We focused on fixing crashes and removing obsolete functionality, improving the developer and troubleshooting experience, increasing OCaml compatibility and JavaScript FFI integration.

Here's a rundown of the key updates in Melange 3. Check the Melange documentation for further resources.

Major Changes and Removals ​

In Melange 3, Belt is no longer a dependency for the Melange Stdlib. Libraries that depend on the Belt modules will need to include (libraries melange.belt) in their build configuration.

The @bs / @bs.* attributes have been replaced. Users of Melange should now utilize [@u] for uncurried application and [@mel.*] for FFI attributes. Additionally:

  • [@mel.val] has been removed as it was redundant in the Melange FFI​​.
  • [@mel.splice] was removed in favor of [@mel.variadic]

For this release, most modules in the Js namespace had their APIs unified, deduplicated and refactored. In cases such as Js.Int, Js.Date, Js.Re, Js.Float, Js.String, some functions were changed from pipe-first to pipe-last and labeled arguments were added; and incorporating those made others obsolete, which we removed. Modules such as Js.List, Js.Null_undefined, Js.Option, Js.Result and Js.Cast are also no longer present in Melange 3. Alternatives within Stdlib or Belt are instead​​ recommended.

New Features and Enhancements ​

Melange 3 includes a few interesting new features and enhancements. From syntax and preprocessing to interop with JavaScript, runtime and error messages, here are some we chose to highlight:

Multiple OCaml-version releases ​

A few users have expressed concerns related to Melange having a 1:1 relationship to its OCaml version. This limitation exists because we vendor and modify OCaml's typechecker, which is usually version-dependent.

In Melange 1, we made some strides to solve this at the syntax level – one Melange version could work across many compiler switches. But that has a pretty big limitation: editor tooling, documentation generation and everything else that reads from .cmt artifact files needed to be in the same compiler switch as the version of the typechecker in use.

Starting in Melange 3, we will be adopting the recent Merlin release strategy: Melange has a release for every compiler version that it supports, suffixed with the OCaml version that it corresponds to, e.g. Melange 3 on OCaml 4.14 is v3.0.0-414.

Interop ​

  • Modules can be renamed with @mel.as
  • @mel.obj and %mel.obj allow renaming the JS object keys with @mel.as
  • @mel.new can now be used alongside @mel.send and @mel.send.pipe
  • [@@deriving abstract] is now deprecated and split into its two main features:
    • [@@deriving jsProperties] derives a JS object creation function that can generate a JS object with optional keys (when using @mel.optional])
    • [@@deriving getSet] derives getter / setter functions for the JS object derived by the underlying record.

Error messages & Hints ​

Melange 3 provides more informative error messages originating from both the melange.ppx and the compiler core​​​​.

In this release, we also introduce a new unprocessed alert to detect code that has made it to the Melange compiler without having been processed by the Melange PPX. Besides hinting users to add (preprocess (pps melange.ppx)) to their dune file, this alert more explicitly exposes a common failure mode that puzzles beginners quite often.

Additionally:

  • The Melange playground now has improved reporting of PPX alerts.
  • Runtime error rendering in the playground renders better error information.
  • The JS parser within Melange has been upgraded to Flow v0.225.1.

Runtime & Stdlib ​

Melange 3 implements more functions in the following modules of the Stdlib: String, Bytes, Buffer, BytesLabels and StringLabels. Specifically, the new unicode parsing functions upstream are now available in Melange as well.

Some keys with legacy names have been updated for consistency, such as renaming RE_EXN_ID to MEL_EXN_ID and BS_PRIVATE_NESTED_SOME_NONE to MEL_PRIVATE_NESTED_SOME_NONE​​ in the Melange generated JS runtime.

The team also took a look at unicode strings in this version of Melange. A few noteworthy changes:

  • {j| ... |j} interpolation​​​​ now only allows interpolating strings; other usages of interpolation have started to produce type errors.
  • Unicode strings such as {js| … |js} can now be used as Format strings.

Conclusion ​

Melange 3 marks a significant step forward in the OCaml-to-JavaScript compilation process. With these updates, we aim to provide a more robust, efficient, and user-friendly tool for developers. We encourage users to upgrade to this new version to take full advantage of the improvements and to adapt to the breaking changes for a smoother development experience. For a full list of the changes that made it into this release, feel free to consult the changelog.

Stay tuned for more updates and enhancements as we continue to improve Melange and support the developer community!

- + \ No newline at end of file diff --git a/blog/posts/dune-universal-libraries-preview.html b/blog/posts/dune-universal-libraries-preview.html index 119a7e033..4b3060bff 100644 --- a/blog/posts/dune-universal-libraries-preview.html +++ b/blog/posts/dune-universal-libraries-preview.html @@ -71,7 +71,7 @@ (echo "let backend = \"Melange\""))) (enabled_if (= %{context_name} melange)))

In short, both libraries get a module C. c.ml's contents vary according to the build context. The example above is currently illustrative, even if functional. We're still working on the developer experience of multi-context libraries. This might not be the best setup for editor support, which we'll find out as we take it for a spin.

Missing Pieces ​

We proved that compiling libraries with the same name in different contexts can work after migrating some of the libraries to the new configuration.

Before deploying such a major change at scale, we need to get the developer experience right. To illustrate some examples:

We will need some additional time to let all pieces fall in their right places before we can start recommending compiling Melange code in a separate Dune context. Before that happens, we wanted to share the problems we faced, how we ended up lifting some interesting limitations in a composable way, and the new constructs that will be available in Dune 3.16.

- + \ No newline at end of file diff --git a/blog/posts/introducing-melange-20.html b/blog/posts/introducing-melange-20.html index 299433696..243d4b7c6 100644 --- a/blog/posts/introducing-melange-20.html +++ b/blog/posts/introducing-melange-20.html @@ -18,7 +18,7 @@
Published on

Introducing Melange 2.0

Authors

Today, the Melange team is excited to introduce Melange 2.0. This iteration brings an upgrade to the OCaml 5.1 type checker, along with increased compatibility with the OCaml Platform. Melange 2.0 unifies the compiler attributes and libraries under the Melange brand and it improves developer experience across the ecosystem. We're also publishing a few battle-tested libraries to OPAM.

Everything we have included in this release has been designed to enhance your experience writing Reason / OCaml for modern JS workflows. Here's a comprehensive look at what's new.

What's New in Melange 2.0? ​

OCaml 5 ​

OCaml 5.1 has just been released. Melange 2.0 has been upgraded to use the newly released OCaml 5.1 type checker and compiler libs. As the OCaml community starts to upgrade to the newest version of OCaml, Melange will be co-installable in your OPAM switch.

While the Melange type checker has been upgraded to the 5.x release line, Melange doesn't yet include support for effect handlers and some of the multicore OCaml primitives. Stay tuned for future updates on this.

The reign of melange.ppx ​

The compiler frontend transformations related to the FFI, extensions and derivers have been fully extracted from the compiler to the Melange PPX. Going forward, it's likely you'll need to preprocess most Melange code with melange.ppx.

Wrapping the Melange Core Libraries ​

In this release, we wrapped the Melange runtime and core libraries. Each library exposes only a single top-level module, avoiding namespace pollution. The only modules exposed by Melange are now:

  • The Js module contains utilities to interact with JavaScript standard APIs. Modules such as Js_string now only accessible via Js.String.

  • The Belt library contains utilities inherited from BuckleScript. Its sub-modules similarly nested under Belt, e.g. you'll use Belt.List instead of Belt_List.

  • Melange 2.0 exposes only a single Stdlib module, where previously it was leaking e.g. Stdlib__String, etc.

  • New libraries: The Node module has been extracted to a new melange.node library. Similarly, Dom is now only accessible via the melange.dom library. Both libraries are released with the Melange distribution, but not included by default; they can be added to the Dune (libraries ...) field.

Enforcing the Melange brand ​

bs.* attributes have been deprecated in this release in favor of mel.*. The uncurried [@bs] attribute is now simply [@u]. The next major Melange release will be removing them entirely. %bs.* extension nodes have, however, been replaced with %mel.* due to limitations in ppxlib. This is a breaking change.

Development experience ​

We've done significant work making Melange easier to use in this release:

  1. Attributes like [@{bs,mel}.val] have been deprecated as they're redundant in the Melange FFI.

  2. We're introducing more ways of using @mel.as in:

    1. let bindings to allow exporting otherwise invalid OCaml identifiers;

    2. external polymorphic variants without needing to use [@mel.{string,int}];

    3. inline records in both regular and extensible variants and custom exceptions.

Ecosystem ​

  • With this release, we're starting to publish some widely used libraries from the melange-community and ahrefs organizations. Be on the lookout for new Melange-ready releases popping up in the OPAM repository in the next few days. Reason 3.10 is also a companion release to Melange 2.0.

  • The new reason-react releases greatly increase developer experience by improving the editor integration. React props and children now point to the correct source code locations, making React components much easier to track in your editor.

  • We've also released an OPAM plugin, check-npm-deps. This tool checks whether the NPM dependencies in your node_modules folder match what libraries released to OPAM need. check-npm-deps is currently in preview and we're looking for your feedback on how we can evolve it.

Support & Sponsorship ​

This release was made possible with the continued support of:

Parting thoughts ​

The goal of Melange is to provide a robust and evolving toolchain that matches the dynamic nature of modern JS development. Melange 2.0 is a testament to that commitment. In this release, we've shipped the majority of our Q3 roadmap. Dive in, explore the new features, and let us know your feedback.

Consult the full change log and the migration guide from 1.0 for a more detailed look at all the changes that went into this packed release.

If you or your company are interested in seeing what Melange can do for your JavaScript needs, feel free to get in touch. We'd love to hear from you.

Happy hacking!

Antonio & the Melange team

- + \ No newline at end of file diff --git a/blog/posts/melange-4-is-here.html b/blog/posts/melange-4-is-here.html index 31c0ab7b0..f08a8e55e 100644 --- a/blog/posts/melange-4-is-here.html +++ b/blog/posts/melange-4-is-here.html @@ -17,7 +17,7 @@
Published on

Melange 4.0 is here

Authors

Today, we're introducing Melange 4.0, the latest version of our backend for the OCaml compiler that emits JavaScript.

Melange is now compatible with OCaml 5.2! In this release, Melange starts emitting more ES6 constructs, supports more JavaScript builtins, improves error handling, and makes using Dune virtual libraries fully supported. Read on for more details.

Embracing OCaml 5.2 ​

OCaml 5.2 was released just last week. With Melange 4, you can now leverage all the power and enhancements in this latest OCaml version. We've upgraded the OCaml type checker and the standard library to match OCaml 5.2's, ensuring you can select a 5.2-compatible Melange in your projects.

This does not mean Melange is only compatible with OCaml 5.2. As previously mentioned in the Melange 3 announcement, each Melange version ships one release for every compiler version that it supports; for OCaml 5.1, this would correspond to Melange 4.0.0-51.

Full Support for Dune Virtual Libraries ​

Melange now fully supports Dune virtual libraries, which requires Dune 3.15.2. There were a few bumps in road when we thought it wouldn't be possible to support this use case in Melange. We were thankfully proven wrong (#1067), and we think that virtual libraries can become an interesting way to write libraries that work across Melange and native OCaml, sharing a common interface.

Emitting ES6 and Enhanced JavaScript Interop ​

In this release, Melange starts emitting ES6, particularly:

  • Melange 4.0 emits let instead of var, and const where possible (#1019, #1059).
  • Emitting let allowed us to remove a bit of legacy code related to compiling for loops, taking advantage of let's lexical scoping. (#1020)

In our effort to expand the API surface area for JavaScript interoperability, we've added new bindings to a few more JavaScript features in the melange.js library (whose main entrypoint is the Js module):

  • Js.Bigint: #1044 added bindings to work with BigInt;
  • The Js.Set and Js.Map modules now bind to even more methods available in these JavaScript data structures (#1047, #1101).
  • JS Iterators: We introduced minimal bindings for JavaScript iterators, making it easier to work with iterable objects, which some other modules' methods can now return (#1060).
  • WeakMap and WeakSet: Bindings for these weakly referenced collections have also been added (#1058).

Improved Error Handling and Code Generation ​

In this release, we've also made significant improvements in how Melange handles errors and generates JavaScript code:

  • Instead of throwing JavaScript objects with Melange exception payloads, we now emit a Melange-specific error (throw new MelangeError(..)) for more consistent error handling (#1036).
    • An interesting corollary to this change is that catching Melange errors from external JavaScript only needs to check instanceof MelangeError.

Additional Fixes & Enhancements ​

  • Slimmer Executable: We've removed unnecessary internal code from melange-compiler-libs, making the Melange compiled executable smaller in size and faster to build (#1075).
  • Float Operations: Fixed runtime primitives for Float.{min,max} and related functions, ensuring more accurate mathematical operations (#1050).
  • Warning 51 (wrong-tailcall-expectation): Melange 4 ships with support for enabling warning 51 and triggering the warning when [@tailcall] is used (#1075).

Conclusion ​

The Melange 4.0 changelog lists all the changes that made it to this release.

Thanks for reading and stay tuned for more updates. Happy hacking!

- + \ No newline at end of file diff --git a/blog/posts/the-rest-of-2023-in-melange.html b/blog/posts/the-rest-of-2023-in-melange.html index 5de3f805f..bc295455c 100644 --- a/blog/posts/the-rest-of-2023-in-melange.html +++ b/blog/posts/the-rest-of-2023-in-melange.html @@ -18,7 +18,7 @@
Published on

The rest of 2023 in Melange

Authors

As October 2023 unfolds, we'd like to present what we're planning to work on during what remains of 2023. Built upon the invaluable feedback of our users and our vision for Melange, we are excited about what's next.

Melange v3 ​

By the close of Q4 2023, we're set to launch Melange v3. Here's a breakdown of our main focus for shipping a new major release:

  • Fast, Reliable Builds: We're fine-tuning Melange to ensure faster, more reliable project builds. This work is spread across a few fronts:

    • implementing some missing compiler and build system optimizations, improving the associated dune rules, and honing the underlying artifact representation for optimal performance.

    • improving the Melange core to be faster to build, run and evolve.

  • JavaScript Expressivity:

    • we're aiming to make JavaScript idioms more intuitive in Melange. We're implementing more supported interoperability attributes, exploring new ways of writing bindings and surfacing their documentation and enriching the existing sections in the Melange docs.

    • we're planning on unifying the Melange core APIs around an abstraction over both pipe operators |> and ->, allowing us to remove some modules where standard library duplication exists, ensuring a more consistent user experience, reducing confusion and evolvability of the code.

    • from supporting React 18 to introducing async component support, we're ensuring Melange stays up to date with the latest in React development. To make is easier to add these, we're planning to safely type JavaScript dynamic import(): this will make code more concise by removing the need for verbose workarounds but also ensures safety, reducing runtime errors

  • Development & Learning Experience

    • With an emphasis on user-friendliness, we're improving the Melange Playground with a few requested features: by the end of the quarter it will offer advanced code diagnostics, bundle the new Melange v2 melange.dom library, present errors and warnings in a more robust way and test a new way of learning how to communicate with JavaScript from Melange.

    • Until the end of 2023, we're going to design and start implementing a whole new Melange website consolidated around a distinct, consistent brand.

    • We're planning to publish Melange for React Devs, a guided introduction for developers with existing React.js knowledge, bridging the gap between React and Melange, showcasing how some common React.js constructs are expressed in OCaml / Reason and Melange.

The Melange Legacy ​

Having integrated with the OCaml Platform set of tools and ensured Melange package availability in the OPAM repository, our previous releases have set the stage for what's next: with Melange v3, we're striving for an even more robust, expressive toolchain with an improved set of learning resources and an unmatched in-browser learning experience on the Melange Playground.

The above is just a glimpse into what we're working on. Consult the full roadmap document for more detail around what we'll be up to until the end of 2023.

Thank you for reading and happy hacking!

- + \ No newline at end of file diff --git a/blog/posts/whats-2024-brought-to-melange-so-far.html b/blog/posts/whats-2024-brought-to-melange-so-far.html index ee8dd99b3..e3e3079ee 100644 --- a/blog/posts/whats-2024-brought-to-melange-so-far.html +++ b/blog/posts/whats-2024-brought-to-melange-so-far.html @@ -27,7 +27,7 @@ - Error: new Error() -}; +});

Besides fixing the immediate issue – vendor SDKs for error monitoring now understand Melange runtime errors – this change brings a few additional benefits to users of Melange:

melange.js keeps getting better ​

The Melange 3 announcement touched a bit on the improvements we did in the Js.* modules recently. We're always trying to improve the number of zero-cost bindings to functions in the JS runtime, and their quality. In next release, we're adding more functions to cover Map, Set, WeakMap, WeakSet, BigInt and Iterator.

We're also taking advantage of Dune's obscure extension that models libraries like the OCaml Stdlib ((using experimental_building_ocaml_compiler_with_dune 0.1) in dune-project, the stdlib field in library stanzas). Here's the difference between a "stdlib library" and a regular library: a stdlib library's main module depends on just a subset of the internal modules in the libraries, while others depend on this main module. Dune doesn't allow regular library modules to depend on their main module name.

In the next release of Melange, we treat the Js.* modules like a "stdlib" library (melange#1091): modules are only accessible through the Js.* namespace; as a fortunate side-effect, we stop exposing Js__Js_internal, which could leak into some error messages, causing unnecessary confusion.

OCaml 5.2 ​

With OCaml 5.2 around the corner (the first beta was released just a couple weeks ago), we made Melange ready for the upcoming release. In melange#1074 and melange#1078 we upgraded both the Melange core and the Stdlib to the changes in OCaml 5.2. As mentioned above, we're happy that the next release of Melange will support an even wider range of OCaml compiler versions, making 5.2 the latest addition to the supported compiler versions.

Leveraging Dune's potential ​

Making Dune faster ​

Back in January, Javi found a performance regression in Dune (dune#9738) after upgrading to Dune 3.13. The whole fact-finding process of profiling Dune's performance and working closely with the team to patch this regression (dune#9769) ended up being quite the learning experience.

Once the dust settled, Javi took the time to write a blog post outlining some of the tools he used and the steps he used to gather information about Dune's runtime behavior.

Improving dune describe pp ​

The command dune describe pp prints a given source file after preprocessing. This is useful to quickly inspect the code generate by a (set of) ppx.

dune describe pp didn't, however, support Dune dialects. I found out about this limitation when trying to get the preprocessed output of a ReasonML file.

We recently set out to fix this problem. In dune#10321 we made Reason files and dialects generally work within dune describe pp, and we followed up with the ability to print back the preprocessed output in the same dialect as the given file (dune#10322, dune#10339 and dune#10340).

Virtual libraries in Melange ​

From Dune's own documentation:

Virtual libraries correspond to Dune’s ability to compile parameterised libraries and delay the selection of concrete implementations until linking an executable.

In the Melange case there's no executable linking going on, but we can still delay the selection of concrete implementations until JavaScript emission – in practice, this means programming against the interface of "virtual modules" in libraries and deferring the dependency on the concrete implementation until the melange.emit stanza.

Or rather, this is now possible after landing melange#1067 and dune#10051: in particular, while Dune support for Melange has shipped with virtual libraries since day one, it didn't support one of the most useful features that they provide: programming against the interface of a virtual module.

Melange rules work within the Dune sandbox ​

Within the last month, we also fixed a bug where Dune didn't track all Melange dependencies precisely during the JavaScript emission phase. While the originally reported issue saw this bug manifest when moving modules across directories when (include_subdirs ..) is enabled, the fix we applied in dune#10286 and dune#10297 brings with it the fortunate side-effect of making Melange rules work in the Dune sandbox. We're glad this issue is fixed since it could result in the Dune Cache being poisoned, leading to very confusing results.

To make sure that sandboxing keeps working with Melange, we enabled it by default in dune#10312 for the Melange tests in Dune.

Towards Universal React in OCaml ​

One of our goals for 2024 is to ship a good developer experience around "universal libraries" in OCaml, the ability to write a mixed OCaml / Melange codebase that shares most libraries and modules pertaining to DOM rendering logic.

Dave wrote server-reason-react for this purpose. He also wrote a post on his blog detailing the motivation behind this approach and what he wants to achieve with server-reason-react.

While React component hydration in native OCaml is a challenge specific to Melange and React codebases, there are reusable primitives that we needed to implement in Dune to make it possible. They also unlock a host of new use cases for Dune that we expect will start getting adoption over time.

Universal libraries are already deployed for a small subset of apps at Ahrefs. Javi wrote about how Ahrefs is sharing component code for those apps.

This past quarter, we took it a step further. We added support in Dune for libraries that share the same name, as long as they're defined in different build contexts (dune#10222). Support for libraries with the same name in multiple contexts landed in dune#10307. We'll be diving deeper into what led us to this solution and what it enables in a separate blog post. For now, the remaining work relates to selecting which build context to use for editor integration when using multi-context builds.

Community at large ​

Bootstrapping Melange projects with create-melange-app ​

In January, Dillon released v1.0 of create-melange-app, and we're now recommending it for bootstrapping new Melange projects

create-melange-app is a friendly and familiar way to get started with OCaml, ReasonML, and Melange, geared towards JavaScript and TypeScript developers.

create-melange-app quickly became a community favorite after its release, attracting a number of contributors that are helping make it better.

Melange Book ​

Feihong keeps making really good progress on our book Melange for React Devs, a project-based introduction to Melange for React developers. The newest chapter on Cram testing guides you through the necessary steps for writing tests and snapshotting their output.

There are more chapters in the pipeline that we'll be releasing incrementally as they're ready for consumption. We're also gathering feedback on the book; we invite you to go through it and open issues in the GitHub repository for any material that deserves rewording.

Looking forward ​

As we look forward, towards the next phase of Melange development, I'd like to take a moment to thank Ahrefs, the OCaml Software Foundation and my GitHub sponsors for the funding and support, without which developing Melange wouldn't have been possible over this sustained period of time.

On a personal note, it fills me with joy to have the opportunity to share the amazing work that Melange contributors have been putting in. It represents a stark contrast from not long ago and the Melange project and community are better for it. Thank you everyone!

As a final note, we thank you for reading through our updates for the first three months of 2024! As we finish planning our work for the next period, we'll share updates on what's to come for Melange in the not-so-distant future.

Until then, stay tuned and happy hacking!

- + \ No newline at end of file diff --git a/blog/posts/whats-next-for-melange.html b/blog/posts/whats-next-for-melange.html index 21a19c8ea..7131dcd39 100644 --- a/blog/posts/whats-next-for-melange.html +++ b/blog/posts/whats-next-for-melange.html @@ -18,7 +18,7 @@
Published on

What's next for Melange

Authors

We're quite happy with how far Melange has come -- I previously wrote about releasing Melange 1.0 and a retrospective on Q2 2023.

But we're not done yet: there's more in slate for the next quarter. I'll tell you what we're looking to achieve in Q3 2023.

We've decided to call the next Melange version 2.0 -- we plan to make a few breaking changes. The main goal for this quarter is to release Melange 2.0. We will focus across a few different axes.

OCaml (and OCaml Platform) compatibility ​

Melange integrates with the most popular workflows in the OCaml ecosystem. Dune builds Melange projects. Merlin and the OCaml LSP power editor integration. OCamlformat and Reason's refmt automatically format code. dune-release publishes Melange libraries and PPX to the OPAM repository. odoc builds package documentation.

In Melange 2.0, we will:

  • Upgrade the Melange type-checker and standard library to OCaml 5.1:

  • Move the Melange internal PPX completely out of the compiler, into melange.ppx:

  • Wrap the Belt and Js libraries:

    • These currently expose all their internal modules. Dune can wrap them nicely under a single top-level module.

  • Break out melange.node:

    • The Node.js bindings are rarely used. We will require melange.node be added to the Dune libraries field.

Developer Experience ​

While Melange already integrates with the OCaml Platform tooling and workflow, there is space to make the experience of developing Melange projects even better.

We want to focus on:

  • Improving the editing experience:

    • Melange can compile FFI externals better, in a way that works better with analysis tools such as Merlin.

    • reason-react-ppx doesn't faithfully respect the JSX node locations. We want to fix that so that "go to definition" works better for Reason JSX.

  • Improving the interaction between OPAM and npm:

    • Melange bridges the OPAM and npm ecosystems. Some packages published to OPAM depend on npm dependencies at runtime.

    • We want to explore solving this issue, starting with a tool that checks that the required npm dependencies are installed in Melange projects.

  • Generating Source Maps:

    • Source Maps allow mapping generated code back to the original OCaml / Reason source.

    • Among other benefits, source maps allow for better stack traces that map to the original lines of code that triggered runtime crashes.

Documentation and Branding: ​

We released melange.re alongside Melange 1.0. The website contains our initial efforts to document Melange workflows, and it can be improved upon. Over the next few months, we will:

  • Develop unified Melange brand guidelines and apply them to the website.

  • Continue documenting Melange workflows:

    • We've already seen some user contributions. We're looking to keep improving the Melange documentation in response to feedback from Melange users.

Wrapping up ​

We have a lot of work ahead of us. The best way to help us is to try Melange. We'd love to read your feedback.

I tried to summarize what we'll be up to in the near future. The full Melange Roadmap for Q3 2023 goes into more detail.

Happy hacking!

- + \ No newline at end of file