GtkSourceView has built-in support for TypeScript.

Vala Tester spawns a command line to run Vala as a REPL.

If we have node-typescript as a dependency, we can run the compiler and still use just the output JavaScript file in the WebView. The issue would be compiler errors. The compiler seems to still compile the TypeScript to JavaScript, but still outputs errors.
Errors get output via stdout (1> filename), not stderr; we can redirect that to a file named error.log, test to see if it has any contents and, if it does, show that on the WebView instead of using the JavaScript file.

In a bit of an extension to #8, we should probably move the handling of the settings into its own file.

Why?

Easier modification of the Settings handler, should the API change

CoffeeScript is a popular JavaScript alternative.

Vala Tester spawns a command line to run Vala as a REPL.

If we have coffeescript as a dependency, we can run the compiler and still use just the output JavaScript file in the WebView. The issue would be compiler errors.
The CoffeeScript compiler does output errors to stderr, so we can actually use out error in the command line spawning to show errors. If there is an error, we can load that into the WebView instead of the JavaScript.

A major issue is that CoffeeScript is not supported in Gtk SourceView, so we would have to figure out a way to add that ourselves. I don't think elementary would accept us installing a CoffeeScript language file to the system.

• We could try to find a way to have this install separately and add /usr/share/com.github.timecraft.jstest/ to Gtk SourceLangaugeManager's search path.
• If enough people want this, we could try to raise an issue to add CoffeeScript as a supported language in Gtk SourceView, as there is not an issue for it already

We need to figure out one of two things:

1. Capture output to JavaScript console in Vala
2. Add a JavaScript console

For 1: I don't know how to do capture that output and haven't found anything online for that.
For 2: The WebKit.WebInspector opens up in a separate window, which is no good.

All this takes is adding a . to the beginning of travis.yml. Should we do this, or should we use Github Actions to do the CI?

Again, #3 requires us to have screenshots of JS Test. Shouldn't be hard, but I would like to wait till I'm sure that this is the UI for the first release before making them

AppCenter ran a bunch of tests on your appstream file. These are the results.

Warnings:

Most of these are fixed during the building process, but you should ensure they
are fixed in your code for future releases.

• "id" field should be "com.github.timecraft.js-test"

For more information, see:

• The AppStream Quickstart Guide
• The AppStream Metadata Specification

Build Information

Affects Architecture: amd64
Affects Distribution: juno
Built with the following references:

• refs/tags/v0.1.0

This seems really clever, but relying on other apps' private API (i.e. their GSettings) is unreliable and error-prone. We have amended the Technical Publishing Requirements to include:

Your app must not attempt to modify other apps or system programs. Your app should not rely on other apps' GSettings, as these are considered internal/private API for those apps.

https://github.com/Timecraft/JS_Test/blob/eb4d66955b4d63b37134c86305b2a1a1be1da5b6/src/Views/SourceView.vala#L67-L94

Currently, if JS Test does not find io.elementary.code.settings or org.gnome.gedit.preferences.editor, it uses the default settings from io.elementary.code.settings which was manually copied over from its schema. On the off chance that we do not find elementary Code or Gnome Gedit, we shoud have a preferences pane to allow for manipulation of JS Test's functionality, or find default editor's schemas to attempt to access

As you might have heard, AppCenter is going Flatpak! For elementary OS 6, we will not longer be accepting Debian packaging, so your app will need to be updated.

We have documentation on our developer guide for writing your Flatpak manifest here: https://docs.elementary.io/develop/writing-apps/our-first-app/packaging#flatpak-manifest

Also, in case you missed it, elementary OS 6 beta 2 is now available. This is a great time to get your app packaged up as Flatpak and test that everything is working before the final release. AppCenter submission for OS 6 will be open soon, so don't delay :)

This relies on #2 being implemented to work out basic problems. It may be more worthwhile to wait until elementary moves to flatpak instead of .debs, as that may reduce the workload.

Before we can submit JS Test to AppCenter, we have to have icons!

Using gschema.xml, which is already present will allow for us to save state.

We should be able to:

• Have a window position; we should be able to put the window where the user last had it.
• Have a window size; we should be able to make the window as big as it was previously.
• Have a pane size; we should be able to make each side of the app (sourceview and webview) the size they were last time the user had the app open.

No matter what method I try, I can't select the body element. It always returns null.

Does not work:

var body = document.body;
var body = document.querySelector("body");
var body = document.getElementsByTagName("body")[0];

Interestingly I can select the <html> and <head> elements.

What does work is to use the console variable $0 in the developer tools to select the body. But from the sidebar codepanel I can't reach it.

I tried restarting the app.

See this issue comment for basic reasoning why.
TDLR; While it is not CI, it should automate changelog creation and version releasing.

As per elementary's README on their actions, it does require a file debian/control and updates to appdata.xml

Upon installing (in a virtual machine), the icon for JS Test is not showing up; it is showing the default icon.

Ephemeral's icon shows up and its icon can be found on manual change of JS Test's .desktop file to point to com.github.cassidyjames.ephemeral, but neither JS Test or Ephemeral can find the icon when pointed to com.github.timecraft.jstest com.github.timecraft.js-test