CodeMirror 5 is now old.

[domesticmouse]

DartPad relies on codemirror.dart which is a Dart wrapper for CodeMirror v5.

Unfortunately, CodeMirror v5 is now old, and CodeMirror has moved to v6.

We should investigate:

• making a CodeMirror v6 wrapper
• making a monaco-editor wrapper
• moving to a Flutter front end

[Rishipan]

hau @domesticmouse i want to work on this issue, plz assign it to me

[domesticmouse]

Hey @Rishipan, if you want to work on this issue I'd suggest filing a new issue with the plan of what you want to do. The above text mentions three separate paths forward, and thus this issue is better suited to being an umbrella issue.

When you have created an issue with your preferred approach, you can work with @johnpryan to sketch out how to integrate the changes, including potentially creating a new dart package that wraps either CodeMirror v6 or Monaco.

[johnpryan]

Should we move this issue to https://github.com/google/codemirror.dart/issues instead?

[domesticmouse]

Should we move this issue to https://github.com/google/codemirror.dart/issues instead?

Well, CodeMirror v5 is going to continue to get minor updates as required so I'll continue to update that package as updates are released upstream.

The question is do we want to invest the effort to wrap a currently in development editor or stay with what we currently have for DartPad.

[johnpryan]

I think the burden is on codemirror.dart to publish a v6-compatible version. I don't see why it couldn't publish both 5.x and 6.x versions, though.

[timmaffett]

(maybe stating the obvious, but ...)

Staying with CodeMirror and moving to v6 would be the least work - however there are still very significant changes to the model of how things work in v6 which would make the transition non-trivial.

Switching to Monaco may bring with it it's own advantages. Moving forward I am sure that being VSCode based and backed by microsoft would both be big pluses.

From a brief investigation the work to move to Monaco vs. CMv6. does not seems to be any more complex and may actually prove simpler because it appears architecturally better. Many things within Monaco will work/appear in ways that are more familiar to users of VSCode and the VSCode Dart/Flutter extensions.
(We get more 'for free' with monaco - see this example - where you can see that The Person class in the code gets analysis and quick fixes - no customization on left was required to configure this). There are many other things shown in the examples here that we could make use of.

A flutter based frontend sounds very interesting - but I image this would be a major undertaking, as we are talking about a code editor from the ground up and html/css over many advantages that both CodeMirror and Monaco can take advantage of that a flutter based frontend would have to recreate from scratch.

I vote ✋ for Monaco.. lol - if changing editor architecture is something that is going to be done.

[domesticmouse]

I think the burden is on codemirror.dart to publish a v6-compatible version. I don't see why it couldn't publish both 5.x and 6.x versions, though.

So I should just simply assign you the task of creating a v6 version of codemirror.dart? Happy to do so.

For context, I'm effectively the sole maintainer of codemirror.dart so stating that codemirror.dart should do something is effectively saying I should do something. Creating a v6 version of codemirror.dart isn't a small undertaking because CodeMirror v6 is effectively a ground up rewrite.

So no, codemirror.dart won't just publish a v6 compatible version. It'll be a new project that will take significant engineering effort to accomplish.

The reason I raised this issue is that we need to make a decision to spend multiple engineer years of effort to build out a future for DartPad's editor component and I can't make that decision alone. It's Google's money to spend, after all.

[domesticmouse]

I vote ✋ for Monaco.. lol - if changing editor architecture is something that is going to be done.

I investigated this a while back and hit the issue that the TypeScript definition to Dart mapping wasn't in great shape. Any ideas of the current state of play in this area?

[timmaffett]

This evening I have been evaluating this new typings package - https://pub.dev/packages/typings
for generating the typescript bindings - it looks like it holds great promise! (and has much improved support for typescript capabilities than js_facade_gen did). He is taking advantage of the newest dart language capabilities to accomplish this.

Interesting wiki page here https://github.com/jodinathan/typings/wiki/TypeScript-to-Dart

the issue dart-lang/language#2995 also has some interesting background by the author.

If this turns out to be capable of making bindings for monaco then (!) I think it should be. In looking through monaco.d.ts is seems like it is not using any language features that his examples npm packages are not also using.

[domesticmouse]

Oooooh shiny. That makes the Monaco approach look feasible. Suhweet.

[johnpryan]

There's a newer issue proposing either CodeMirror 6 or Monaco, so I'm going to close this one.