Package definition can already be exported to a file using $system.OBJ.Export("Foo.Bar.pkg",filename)

Yes, it's XML format rather than prettier UDL, but it can still be used to manage the definition in file-based source control.

See also https://community.intersystems.com/post/announcing-jupyter-server-proxy-... for the original announcement of this. 

https://openexchange.intersystems.com/package/Jupyter-Server-Proxy-for-V... approaches this from another angle. 

I find the borders too narrow (1.5px) to show me the colour. Maybe also use different values for border-radius, e.g. 5% for staff, 30% for mods.

This is a good reason for implementing the server-centric paradigm for code editing and for source control. We at George James Software have a growing number of sites that use our mature and powerful Deltanji tool, which handles deployment as well as versioning, is hugely flexible and configurable, and now has a unique ability to manage the individual configuration items of an interoperability production. Deltanji runs within the InterSystems platforms, handling your code where it is runnable instead of constantly having to export and reimport it. Deltanji can also handle code artifacts that live outside the InterSystems platform, such as images, scripts and stylesheets.

If the existing (large) application consists of a lot of ObjectScript artifacts (routines, globals, and maybe some classes) did you consider using Deltanji, an ObjectScript-native source code management solution? No Git involved, so none of the export/import that approach requires.

As well as versioning the code it handles the whole workflow, making it easy to promote changes from dev namespaces via test ones to production / packaging ones.

@Ephraim Malane did you edit the title of this thread? It's now "." which looks odd in the DC lists.
 

@Guillaume Rongier Thank you for opening the issue on GitHub. I created a PR yesterday and hope you will be able to verify the fix soon. Then we'll see about publishing a new version of the extension.

Are you using VS Code for your debugging? Or Studio? Or the command line?

The first of these issues was previously described in my post at https://community.intersystems.com/post/one-reason-vs-code-being-unable-...

As for the second, do you think the message displayed by the extension needs improvement? 

How about creating a dedicated directory, then using the info at https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity#change-th... to make Windows treat it case-sensitively?