The AAS WorldWide Telescope WebGL engine

The “WebGL engine” of the AAS WorldWide Telescope (WWT) is a JavaScript/TypeScript framework that powers the Web-based versions of the WWT visualization software, as exemplified by the WWT web client.

Learn more about WWT here.

Developers’ quick start

Check out this repository to a machine with Node.js and npm.
git submodule update --init
npx lerna bootstrap -- --legacy-peer-deps (You may be able to omit the arguments here, depending on your version of NPM. See this bug.)
Either build or obtain the file engine/wwtlib/bin/wwtlib.js as described below.
npm run lint (uses ESLint)
npm run build creates:
1. The core engine package in the engine/ package.
2. The engine tidied up into a Vue/Vuex module in engine-vuex/
3. The WWT embed app intended for iframe inclusion in embed/
4. The WWT research app in research-app/
5. The user-facing app for creating embed iframe code in embed-creator/
Commands to serve the web apps:
1. npm run serve-embed to serve the embed app
2. npm run serve-research to serve the research app
3. npm run serve-creator to serve the embed creator app
npm run test (mainly uses mocha and chai)
npm run doc (uses TypeDoc)

Repository structure

This repository is a monorepo containing the source for several interlocking TypeScript packages that together comprise the core of the WWT web framework. The most important subdirectories are:

@wwtelescope/engine in engine/, the core engine code transpiled from C# and wrapped in TypeScript annotations
@wwtelescope/engine-vuex in engine-vuex/, a higher-level package that turns the engine into a reusable Vue/Vuex component
@wwtelescope/embed in embed/, a web application that turns WWT into a configurable, embeddable iframe
@wwtelescope/research-app in research-app/, an embeddable web application for astrophysics research using WWT.
The narrative documentation in docs/

README files inside the individual subdirectories give more information about their contents and development workflows.

The `engine/wwtlib/bin/wwtlib.js` file

There’s one big wrinkle to the build process: the bulk of the engine code is actually C# code in the directory engine/wwtlib/. It’s forked from wwt-windows-client and is transpiled into JavaScript using an unreleased version of ScriptSharp, an unmaintained tool. Fortunately, that build process results in a single file, engine/wwtlib/bin/wwtlib.js, that you can download from our CI systems if you’re not able to perform a Visual Studio build.

To build the engine library starting from C#:

You need a Windows machine with Visual Studio 2017. Other versions of Visual Studio might also work.
Open the engine/WebGLEngine.sln solution and build the project it contains. This should create the file engine/wwtlib/bin/wwtlib.js.

Otherwise, check out the latest continuous integration build of this repository, download the scriptsharp artifact, and copy the wwtlib.js file to the location given above. (To find the artifact, go to the appropriate build in this project's pipeline on Azure DevOps). Under 'Related', select '9 published', and download artifacts for scriptsharp). If you want to change the C# code, you can file a pull request and access the artifacts associated with your pull request builds.

Building the rest of the code

Besides the creation of the file engine/wwtlib/bin/wwtlib.js, virtually everything in this repository is built using standard Node.js/npm tooling. These tools must be installed before you can do anything else.

The multi-package structure of this repository is dealt with using Lerna. This means that once you’ve checked out the code and install npm, the setup sequence is:

Run git submodule update --init to pull in needed Git submodules, namely the documentation theme in docs/*/themes/wwtguide.
Run npx lerna bootstrap to install all of the project dependencies and set up the necessary cross-links between individual packages in this repository.

Once setup is complete, the following commands will be useful:

npm run build to build the subpackages
npm run lint to lint the subpackages (using eslint with TypeScript extensions)
npm run test to run the tests (mainly using mocha and chai)
npm run doc to build most of the documentation (using TypeDoc) — but see below

Running these commands from inside package subdirectories unfortunately will not work due to the centralized node_modules directory we use with Lerna. To run the lint command only for the engine-types submodule, run:

npx lerna run --scope @wwtelescope/engine-types lint

(The --scope argument can be a glob expression if you want to run on a subset of packages.)

Building the full documentation

Documentation is maintained in subdirectories of docs/. The documentation is a Frankenstein combination of the autogenerated API documentation and narrative material written in CommonMark Markdown. The final HTML is assembled with the static site generator Zola,

Zola is fast and self-contained and ridiculously easy to install.
The npm run doc command will install the autogenerated documentation into docs/engine/static/
Running zola build in a subdirectory of docs will assembled the final HTML into docs/{subdir}/public/.
The command zola check will check the narrative docs for broken links.
The command zola serve will serve the documentation using a local server with autoreload.

Continuous Integration and Deployment

This repository uses Cranko to automate release workflows. This automation is essential to the smooth and reproducible deployment of the WWT web services.

Integration Testing

Integration testing of the apps is done using Selenium, Nightwatch, and BrowserStack. For the main branch, this is triggered automatically with each commit/pull request. However, the test suite can also be run using a version of the app on your local machine, either locally (using the Nightwatch binary) or using BrowserStack (provided that you have a BrowserStack account). In either case, you may need to modify the url in tests/page_objects/researchApp.js to point to the localhost port that you will be using (the default is http://localhost:8080).

To run the test suite on a local version of the app with ChromeDriver:

npm run serve-research &  # or equivalent
cd tests
npm install
npm run build
npm run local

To run tests on a local version of the app via BrowserStack's multi-browser, multi-platform infrastructure, do the following:

Set the variables BROWSERSTACK_USERNAME and BROWSERSTACK_ACCESS_KEY to your BrowserStack username and access key, respectively. You can find these values in your BrowserStack Account Settings.

Run the test suite as above but with the final command: npm run bs-local

By default, both of these local options will run the tests in Chrome. You can adjust the testing environments adding the -e option, which can be accomplished with syntax such as

npm run bs-local -- -e firefox,edge

Getting involved

We love it when people get involved in the WWT community! You can get started by participating in our user forum or by signing up for our low-traffic newsletter. If you would like to help make WWT better, our Contributor Hub aims to be your one-stop shop for information about how to contribute to the project, with the Contributors’ Guide being the first thing you should read. Here on GitHub we operate with a standard fork-and-pull model.

All participation in WWT communities is conditioned on your adherence to the WWT Code of Conduct, which basically says that you should not be a jerk.