Try โ€‚โ€‰HackMD

WIP INTERNAL TO OCAML PLATFORM TEAM - DO NOT SHARE

Welcome to the twelfth edition of the OCaml Platform newsletter!

In this June 2024 edition, we are excited to bring you the latest on the OCaml Platform, continuing our tradition of highlighting recent developments as seen in previous editions. To understand the direction we're headed, especially regarding development workflows and user experience improvements, check out our roadmap.

Highlights:

  • First release of project-wide occurrences queries for editor tooling. The design of the feature will be presented at the OCaml Workshop in September.
  • TODO: opam 2.2 and workshop talk

Releases:

[Dune] Exploring Package Management in Dune (W4)

Contributed by: @rgrinberg (Tarides), @Leonidas-from-XIV (Tarides), @gridbugs (Tarides), @Alizter

Why: Unify OCaml tooling under a single command line for all development workflows. This addresses one of the most important pain points reported by the community.

What: Prototyping the integration of package management into Dune using opam as a library. We're introducing a dune pkg lock command to generate a lock file and enhancing dune build to handle dependencies in the lock file. More details in the Dune RFC.

Summary:

In last month's newsletter, we announced the Dune Developer Preview program, which marked our transitioning from prototyping Dune package management to user testing in preparation to a public release. We are now focusing on iterating based on feedback, aiming to develop a robust version of Dune package management that's suitable for widespread use in OCaml projects.

Based on our initial user interviews, this month included the following improvements:

  • Implementing auto-locking when dependencies change in dune-project (particularly useful with Dune watch mode)
  • Enabling automatic installation of OCamlFormat when running dune fmt. We're particularly excited about this feature and plan to extend this workflow to other Platform tools used by Dune.
  • Improving logs
  • Making package locking cancellable
  • And more

We've also begun upstreaming some of the features developed during the Developer Preview to Dune's main branch.

Activities:

[opam] Native Support for Windows in opam 2.2 (W5)

Contributed by: @rjbou (OCamlPro), @kit-ty-kate (Ahrefs), @dra27 (Tarides), @AltGr (OCamlPro)

Why: Enhance OCaml's viability on Windows by integrating native opam and opam-repository support, fostering a larger community, and more Windows-friendly packages.

What: Releasing opam 2.2 with native Windows support, making the official opam-repository usable on Windows platforms.

Summary:

Opam 2.2 was released and announced on Discuss. The release comes with native support both for the opam client itself, and also for the compiler's packages in opam-repository!

The community has already started rallying to make the opam-repository more usable on Windows, including adding a CI check for Windows compilation on package submission (by @kit-y-kate at opam-repository#26069. They also started upstreaming opam-repository-mingw patches for core packages, like OCamlBuild (by @hhugo at opam-repository#26164.

The GitHub Action ocaml/setup-ocaml version 3.0.0 now uses opam 2.2.0 to bring OCaml support, and is ready to use in your GitHub projects (by @smorimoto). It's already in use in core projects, like Dune.

This release marks the end of the project, but the effort to create a delightful user experience for Windows users is far from being over! Now that the foundational building blocks support Windows, we as a community need to rally to make as much of the opam-repository packages Windows-compatible as possible. If you're a package author, we strongly encourage you to setup a Windows CI for your project and start addressing Windows-related issues on your packages.

Activities:

[odoc] odoc 3.0: Unify OCaml.org and Local Package Documentation (W25)

Contributed by: @jonludlam (Tarides), @julow (Tarides), @panglesd (Tarides), @EmileTrotignon (Tarides), Luke Maurer (Jane Street)

Why: Improving local documentation generation workflow will help package authors write better documentation for their packages, and consolidating the different odoc documentation generators will help make continuous improvements to odoc available to a larger audience.

What: We will create conventions that drivers must follow to ensure that their output will be functional. Once established, we will update the Dune rules to follow these rules, access new odoc features (e.g., source rendering), and provide similar functionalities to docs.ocaml.org (a navigational sidebar, for instance). This will effectively make Dune usable to generate OCaml.org package documentation.

Summary:

With the RFCs for odoc 3.0 completed and shared with contributors and the community for feedback, the odoc team is transitioning from planning to implementation of the designs and features outlined in the RFCs.

This month's progress includes:

  • Adding new options to the odoc CLI to begin the implementation of the odoc 3 CLI
  • Implementing new syntax such as path-references
  • Developing the global sidebar with a TOC featuring standalone pages and package module hierarchy

In the coming weeks, the team will continue this work, but it will also start looking into integration points with odoc 3.0, including Dune rules and integration with the OCaml.org documentation pipeline.

Activities:

[Merlin] Support for Project-Wide References in Merlin (W19)

Contributed by: @vds (Tarides)

Why: Enhance code navigation and refactoring for developers by providing project-wide reference editor features, aligning OCaml with the editor experience found in other languages.

What: Introducing ocamlmerlin server occurrences and LSP textDocument/references support for project-wide queries. This required indexing projects with local indexation using Shapes done in the compiler, a Dune-orchestrated global indexation, and the integration of these features in Dune, Merlin, and OCaml LSP.

Summary:

As announced a few weeks ago, Merlin project-wide references is now available in Merlin 5.1 and the preview of OCaml LSP 1.18.0. Users of LSP-powered editors (like VSCode with the OCaml Platform extension) and classic Emacs and Vim plugins can now query project-wide references of OCaml terms. This requires building the index with the new Dune alias @ocaml-index.

This release represents the culmination of a multiyear effort by the Merlin team, including extensive work on the compiler to provide the necessary information for implementing this feature in Merlin.

We're beyond excited to share this feature with the community and look forward to your feedback.

While the feature should work well in most cases, we're aware of some limitations. Our next steps include adding support for interface files and module paths. Stay tuned!

Activities:

[OCaml LSP] Bridging the Gap Between Merlin and OCaml LSP (W19)

Contributed by: @xvw (Tarides), @vds (Tarides)

Why: Merlin and OCaml LSP currently offer different feature sets, creating inconsistencies in editor support. By achieving feature parity between the two, we aim to make OCaml LSP the comprehensive backend for OCaml editor support. This will provide users with a more consistent, feature-rich development experience across all editors, including Emacs and Vim.

What: We are upstreaming features from OCaml LSP, such as the signatureHelp request, and ensuring we expose every Merlin feature from OCaml LSP, either through requests or custom code actions, such as type-enclosing request.

Summary:

In June, we started work on bridging the gap between OCaml LSP and Merlin. We've started with exposing Merlin's type-enclosing request in OCaml LSP. The feature is now available as ocamllsp/typeEnclosing.

As a reminder, Merlin's type-enclosing feature allows users to get the type of the identifier under the cursor. It highlights the identifier and displays its type. Users can climb the typed tree to display the type of larger expressions surrounding the cursor.

Activities