Skip to content
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

Handle local type definitions in Monaco #2883

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

josephjclark
Copy link
Contributor

@josephjclark josephjclark commented Jan 30, 2025

Overview

There are two fixes in this PR:

  1. A devtime fix for local adaptors mode, enabling type definitions used by the editor to be pulled from the local monorepo
  2. A fix to Monaco's type support, which makes typings lookups a little better and also fixes a bug uncovered by the fhir-4 adaptor.

The upshot of this is: if you're developing an adaptor locally and you want to see whether the typings are working in Monaco, you can.

This PR does not address the issue of fixing adaptor docs locally.

Local Adaptors

So if you do LOCAL_ADAPTORS=true mix phx.server, Lightning will very cleverly go off and load adaptors straight out of your monorepo. Neato.

There are two things that break:

  1. Monaco will try and look up typings for the currently loaded adaptor, and will fail.
  2. Adaptor docs will try and generate typing for the currently loaded adaptor, and will also fail.

This PR addresses the first point by telling Monaco's supporting code to load @load adaptor definitions from a local server.

What local server, you say?

TODO: local serve support

I could use some help here!

For this to work right now, you have to go into adaptors and run PORT=5000 npx serve --cors to create a local web server to host requests for d.ts files.

This is fine, and I could just go off and document this. But before I do: could we have Lightning run that command if LOCAL_ADAPTORS is set? Then this stuff can just work automatically.

QA Notes

It would be great to go through a couple of key adaptors (including dhis2 metadata) and ensure that language support is consistent across this branch and main. There's one change which I'm a little worried about.

Note that I think metadata for dhis2 is actually broken in production right now. I need to investigate separately.

AI Usage

Please disclose how you've used AI in this work (it's cool, we just want to know!):

  • Code generation (copilot but not intellisense)
  • Learning or fact checking
  • Strategy / design
  • Optimisation / refactoring
  • Translation / spellchecking / doc gen
  • Other
  • I have not used AI

You can read more details in our Responsible AI Policy

@josephjclark josephjclark self-assigned this Jan 30, 2025
Copy link

codecov bot commented Jan 30, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.44%. Comparing base (3c438ea) to head (ee69910).
Report is 31 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2883   +/-   ##
=======================================
  Coverage   91.44%   91.44%           
=======================================
  Files         343      343           
  Lines       12351    12351           
=======================================
  Hits        11294    11294           
  Misses       1057     1057           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Icebox
Development

Successfully merging this pull request may close these issues.

1 participant