If I want to use it locally there is a documentations?
I think as example for an event or hackaton.

I asked @JeremiePat about a good documentation strategy for Janitor, and he sent me this fantastic email:

When documenting a product the question you should ask yourself is: Who will need that documentation and for what purpose?
Regarding your project, I can identified two type of people: Developers who want to use Janitor and developers who want to hack it.

For those who want to use it, I think you already have a good starting point with the Janitor Web site and the readme file in the github repository. In that area my suggestion would be to:

• enhance the readme file and mirror it on the Janitor web site.
• add a FAQ on both the web site and github to answer common install troubleshooting issues.
• create tutorials to demonstrate each individual user facing feature of Janitor, and make them available on the web site.

For those who want to hack it, it is a little bit more complicated as it is necessary to provide different information at different level:

• Providing a high level architecture document will help new comers to get use to the organization of the code base
• Provide building and testing documentation (with solution to well known issues)
• Also providing a document with the "rules" to follow for contributing (code standard, test policy, review process, etc.) This can safely live on the github wiki or on wikimo as you wish. Such documentation is usually quite fluid as it changes along the life of the project so a Wiki is a good place for that.
• For people who will hack the code, I always recommend to document as close as possible from the source code to avoid having people looking everywhere for information (it's time consuming and inefficient). However, if, for example you have a good documentation inline with the code, I always suggest to use tools (like Sphinx, Doxygen, JSDoc, etc.) to extract and build a more human friendly documentation. Such documentation can be host on the Janitor web site. The big advantage is that by using such tools in addition to a review requirement for inline documentation you'll get up to date documentation at a low cost.

This is a start, I suggest to prioritize the documentation work by asking new comers what information they are missing. This will give you a good hint of what is important in the short term. I also suggest to make documentation part of the acceptance criteria for pull request, that way you'll reduce the documentation debt (only legacy stuff will require some effort) and you'll start create a culture of documentation for the future which will make things easier along the way.

Additionally, I think we should:

• Add Janitor to Janitor (#31) which should make hacking Janitor much simpler
• Centralize all documentation links directly in README.md
• Add an "about" page (#5) with a high-level overview of how the Janitor works; what's required to use it; and maybe what we're trying to achieve with it
• Create a Discourse (#26) which is great for writing documentation where it's needed the most
• Show the SelfAPI automated documentation (#66) for the /api/* folder directly on the website (e.g. at https://janitor.technology/reference/api/)

If you have another idea that could improve Janitor's documentation, please comment below. Thanks!

The Makefile currently offers a way to generate self-signed HTTPS certificates with make https, which is used in make install. (It also offers a way to just generate a CSR with make https.csr, in order to manually get it signed by a trusted CA.)

This should be deprecated in favour of automated Let's Encrypt renewal. The code for this is already in place, and just needs to be automated.

Username on C9 is also notriddle.

Implementing a service worker in the Janitor web app could significantly improve subsequent load times, and make it (somewhat) usable offline.

When using the Kresus container, for which one can spawn a web service running on port 9876, there's no way to discover that the Docker instance has bound the port 9876, and thus to navigate to the URL in the proxy. As a workaround, one can just click the VNC button and change the port in the URL. But things could be simpler: maybe a section with links/buttons (one for each hosted service), which redirects to the service once clicked?

I tried to install it on Debian 8, but I failed.
First I had to symlink /usr/bin/node to /usr/bin/nodejs

Then I started a ubuntu container, leading to the same result.
I noticed in the error messages, service not found so I am running a container with ubuntu:16.10 now.

However, am I assuming correctly the readme should state Debian 7 or Ubuntu 16.10?

I think it would be important to be able to view a list of connected devices for an account and remove a device from using Janitor.

At the moment, users can sign in by clicking a link sent by email.
Here are other ways a user might want to use in order to sign in.
As @jankeromnes pointed out, the list should be split.
The first list is for sign-in only methods:

• Sign in with a Time-based One-Time Password (using an authenticator app) ( RFC6238, speakeasy: node implementation )

The second list is for signing in with/authorising other services and automating some features in interaction with these external services:

• Sign in with GitHub
• Sign in with Phabricator

The Janitor started out installing Shipyard as a dependency, to allow scaling the Janitor to multiple hosts in the future if needed.

In the meantime, Docker implemented native clustering with Docker Swarm, so we might not need to depend on a third party tool for scaling issues anymore.

I am working on a website with some teammates, it would be nice to have access to the services of The Janitor to enhance the experience for everyone :)

@jankeromnes Great initiative, love this idea! :)

Really want to see that open source project be supported on the Janitor? Please comment here, and it will be added to the list (if that makes sense).

TODO:

• Firefox
• Chromium
• Thunderbird
• Servo
• KDE
• Kresus (repository, dockerfile)
• Janitor (this repository, was #31)
• Discourse (dockerfiles)
• PeerTube (dockerfile)
• Firefox for Android (dockerfile, using fennec emulator, c9's android dockerfile, g+ post, added in JanitorTechnology/dockerfiles#147)
• Rust (repository, added in JanitorTechnology/dockerfiles#153)
• Git (repository)
• LLVM/Clang/LLD (getting started docs)
• GCC (svn docs)
• Mozilla RelEng Services (dockerfile)
• TensorFlow
• Keras
• Bugzilla (dockerfile)
• ChakraCore (repository)
• TheFileTree (repository, dockerfile, was #14)
• AppInventor (dockerfile, was #13)
• Swift
• WebKit (git://git.webkit.org/WebKit.git)
• Cordova (repositories)
• TOR (repositories)
• Stellarium (repository)
• Celestia
• FlightGear
• Kubernetes
• Kuma and Kumascript (uses several containers for development, might be tricky from inside of a container)
• Bitcoin Core (repository)
• Wordpress (vagrant with scripts)
• Electron
• Mixxx
• Qt
• Samsung Browser
• Angle
• Cloud9 IDE plugins / Cloud9 SDK (repository)
• Add-on reviewing
• Bors-NG

Splitting this issue from #24 (comment) for tracking purposes. Please react with 👍 if you like the split or feel free to close as dupe if you prefer to track exclusively with that issue.

After building Chromium content_unittests in Cloud9, I'm failing to run

$ xvfb-run -s "-screen 0 1024x768x24" ./out/Default/content_unittests --gtest_filter=BluetoothAllowedDevicesMapTest.*
xvfb-run: error: Xvfb failed to start

For info, it works great with noVNC.

Add the MIT AppInventor project on Janitor, following the Dockerfile:
https://github.com/josmas/appinventor-env-docker/blob/master/Dockerfile

When closing the original terminal tab and opening a new one, some functions (like doing an interactive rebase) will not work anymore, because git cannot find an editor. This is due to the EDITOR environment variable being unset.

As I can see after the registration on c9.io is required a princing plan.
But I can see that is only a ssh connection so i think that is possible to use it without c9.io.

A quick description on the projects page for each project and what's included in it would be useful to those preparing to set up a contribution.
Particularly the KDE project could use this, as it's very unclear what components of the KDE project are included.

A link to the version control or primary documentation resource of each project wouldn't hurt either.

I'm working on Servo, so contributions are made using GitHub. Since Janitor doesn't link to GitHub in any way, running git push with the intent of creating a pull request asks for my GH username and password. Normally, this would work...

But I have two-factor authentication turned on. You can do it with a personal access token, but that is a gigantic pain.

Could we have the Janitor request a token itself with oAuth?

Sometimes, a contribution environment can become stale and irrelevant, to the point where it's more convenient to create a brand new one than to update the old. In that case, it's easier to just delete the old.

A page that explain how works the project, the requirements to use (cloud9 account as example).
That video is not enough https://www.youtube.com/watch?v=5sNDMIh-iVw

I have an old container (10 months ago) of Firefox, when I click on VNC i get a blank page so I wanted to delete.
On delete I get an alert with:

Error: (HTTP code 404) no such container - No such container: 293f90b839179175b8406684c2149992635cbfe86e9ef39dceea732d8985ece3 

In any case I don't find a way to create a new one for firefox.

There are several issues with project Dockerfiles that need to be fixed before the beta milestone, specifically:

• Support chrome_sandbox for Chromium https://github.com/jankeromnes/dockerfiles/issues/4
• Fix Chromium update (rebuild step) https://github.com/jankeromnes/dockerfiles/issues/5
• Switch Chromium builds to GN https://github.com/jankeromnes/dockerfiles/issues/9
• Fix Thunderbird build https://github.com/jankeromnes/dockerfiles/issues/7
• Fix Servo crash in noVNC https://github.com/jankeromnes/dockerfiles/issues/8
• Can't login to KDE in noVNC

Add TheFileTree project on Janitor, following the Dockerfile:
jankeromnes/dockerfiles#1

Currently, an active Janitor instance offers root access over a web remote desktop connection (using NoVNC) to anyone who knows the right link.

Instead, only the owner of an instance should be able to access it. This could be enforced by an authenticated proxy that only grants remote desktop access to the owner of an instance.

Once https://github.com/JanitorTechnology/janitor/projects/2#card-3182746 is done, we should be able to replace the "Edit in Cloud9" button in the screenshot below with a "connect to your container" or something along those lines, and skip connecting to Cloud9.

The link has this form: https://moz1.janitor.technology/<container>/8089/ide.html (the container is the same as the one in the VNC button).

To guide and encourage new contributions to the supported projects, it would be helpful to 1) add IDE buttons to update, build and run projects, and 2) show instructions on how to access the contribution environments in different ways, with links to further documentation where useful.

Project-specific IDE buttons:

• Chrome: Update with gclient sync -j18, build with ninja -C out/Default chrome, run with out/Default/chrome.
• Firefox: Update with git pull --rebase origin master, build with ./mach build, run with ./mach run.
• Thunderbird: Update with python client.py checkout, build with ./mozilla/mach build, run with ./mozilla/mach run.

Contribution-specific instructions:

• IDE access: Click the button to enter the Cloud9 IDE web interface.
• VNC access: Click the button to enter the noVNC web interface.
• SSH access: Add personal SSH public key to account (TODO) then use ssh [email protected] -p XXX to log in.

Thanks to @beaufortfrancois for the suggestion!

Thanks @FrancoisChastel for the suggestion!

When using a service that's hosted in a container, e.g. a Web service, then the user can access the Web service, and all the requests get proxied through Janitor (which does a simple redirect). However, some methods aren't getting properly redirected: I have seen instances where POST, PUT, DELETE methods wouldn't ever reach the web service in the Docker instance.

Janitor is in English at the moment, which is nice, but some people would probably be more comfortable using their native language there. Moreover, it's easier to implement a translating framework at the beginning of a project than later; so even if it's used only for English at the moment, it'd be nice to have.

Internationalization would probably be minimal work: I've just seen a few dates printed out on the website.

• English (en-us)
• English (en-ca) Request by @Coder206
• French (fr)
• Brazilian (pt-br)
• Russian (ru)
• Japanese (ja)
• Dutch (nl)

@jankeromnes I was trying to access one of my accounts today (about 5 minutes ago was my latest attempt - it took me all day to find the time to open the Spam folder... :( ). I went to the website and signed in, I provide my email, and found the link. When I followed it, the website looked fine, then when I came to click any of the tabs (eg, Settings, Projects or Contributions) my account would log out and look the way it did before providing my email. I also tried the Sign out button, this one was working as expected bringing me back to the main page. Not sure what to make of this...

• I've done developing with your own developer tools, and if nothing else it gives you rapid feedback on all the problems. You will fix all the annoying crap just to be able to not deal with it yourself.
• The most painful part of setting up dev environments for webapps like this is dealing with the external services like GitHub that you can't just host yourself. If you can automate all the setup work needed for a developer instance of an app that runs on GitHub, I'd be very interested in getting aelita running on janitor.
• I want to be able to run the Janitor in the Janitor so I can code while I code.

Today, for every new contribution on the Janitor, there are a number of repetitive steps you need to perform in order to configure your environment properly. It would be great to automate these steps, e.g. by letting users add their desired configurations once and for all to their Janitor account, and automatically apply them to all your contributions.

Here are the configurations we'll aim to support:

• Cloud9 username (to link your Cloud9 and Janitor accounts) (we no longer use the third-party c9.io service)
• Cloud9 SSH public key (to authorize Cloud9 IDE to access to your contributions) (same as above)
• Personal SSH public keys (to authorize SSH access to your contributions from anywhere)
• Dedicated SSH key pair (to allow pushing from your contribution environment e.g. to GitHub)
• Git/Mercurial preference (to prefer one over the other for contributions where both are supported) (not really a user preference, but a different project setup)
• .gitconfig (to preconfigure e.g. user.name, user.email, core.editor and credentials like bz.username and bz.apikey)
• .gitignore (to make sure contribution internals are ignored, e.g. the .c9/ folder in your workspace)
• .hgrc (to preconfigure ui.username, enable extensions like mq, specify the desired patch format)
• .config/hub and .netrc to auto-configure hub like this
• .gdbinit (e.g. to ignore SIG38 and SIG39 by default, and add add-auto-load-safe-path /home/user/firefox/.gdbinit or set auto-load safe-path /)
• .eslintrc
• .vimrc
• .emacs
• .nanorc
• Bash/Zsh preference
• .bashrc (e.g. for aliases, completion behavior, and to set a custom PS1 prompt)
• .zshrc

If you feel that something important for your work is missing, please comment below and I'll update the list.

It would be great if we could run a noVNC of an OSX machine.

Today, once you've created a contribution environment for a project (bootstrapping from scratch in less than 3 seconds), you're pretty much left on your own for the rest of the work to finish your contribution and get it merged into the project upstream.

It would be great to automate most of the contribution process, and let the Janitor take care of any repetitive or time-consuming workflow steps for you. This can be achieved by customizing Cloud9 IDE for any given project.

Here are the Cloud9 IDE plugins we would like to build for most Janitor projects:

• Button to update the project's source code (and maybe rebase any local modifications on top)
• Button to build the project from its sources
• Button to run the project (for desktop projects like Firefox and Chromium, this implies a noVNC preview, e.g. with c9.ide.desktop)
• Button to send your local modifications for code review (e.g. by uploading a patch and requesting feedback from someone qualified)
• Push notifications (to let users know about IDE events like "Build successful", see the "Cloud9" part of #22, idea from @Coder206)
• Show linting feedback in the editor (display project-specific compiler warnings / linting problems right next to offending code, use tools like clang-tidy, clangd (in review), rust language server (how to), rust-clippy, eslint, etc)
• Show coverage feedback in the editor (show which portions of the code are not covered by any tests yet using code coverage tools like codecov.io, idea from @sylvestre)
• Show review feedback in the editor (display comments from an associated code review directly in the editor for convenience, idea from @notriddle) @nt1m started working on implemented this.
• Offer coding helpers in the editor (apply technologies like ctags and clang-tidy to allow symbolic navigation in the project's source code and offer powerful one-click fixes / refactors from the editor's UI, idea from @sylvestre)
• Show a debugger front-end (to combine the clarity and speed of great UI with the power of gdb and rr)
• Alphabetically sort any selection of lines

If you have another idea how the Janitor's IDE could be tuned to accelerate/empower your development on a project, please explain it below and I'll add it to the list.

EDIT: Here is a great video lecture by Harvard University on Cloud9 IDE and how to write plugins for it.

Implement Push Notifications (using Push API) so that users can receive valuable information notifications all within Janitor, if they desire.

I am planning on working on this, I am open to comments and ideas.

We would like the Janitor web app to offer developers more visibility and control over their containers, so that they can do more with their containers, and troubleshoot common problems more easily.

Additionally, new container features should also be available in the upcoming Janitor API.

To improve the view and tools of Janitor containers, we should implement the following changes to Janitor's web app and server:

• Rename "Contributions" to "Containers" on the website (also, /contributions/ should redirect to /containers/)
• Make the existing "Firefox #0" container label editable (so that you can give it a name that reminds you what you use this particular container for, e.g. a feature you're implementing, a bug you're fixing, some tests you're running, etc) (@bnjbvr started this in #70)
• The (now empty) "Logs" text area should be replaced with a button (or "toggle-able text area") that allows you to start streaming live Docker container logs (feature removed in 38bf720)
• Add templated instructions describing how you can access your container via SSH (i.e. an ssh one-liner with the correct host, port, and a link to the Settings section where you can authorize personal SSH public keys) (done by @nt1m in fe6dd42)
• Add buttons/links to access exposed container ports different from SSH (22), noVNC (8088) and Cloud9 (8089), for example Kresus containers should have a link to access their port 8080 (to preview the running Kresus web app through the Janitor proxy with a URL like /abcdef0123456789/8080/) (was #53)
• Add a simple "diff view" to quickly see what was modified in this container (for example, the list of added/changed/removed files, or maybe a full diff if that's reasonable) (@nt1m might do this I added this to the admin page in #161)
• Display the container ID somewhere (EDIT: Is this really useful?)
• Display the container's host somewhere (EDIT: Is this really useful?)
• Display the container's disk size footprint (actual size of the container, and also the total size of older Docker images you're preventing from being garbage collected)
• Display the actual Docker container status (running, stopped, not found) instead of what Janitor thinks the container status should be
• Add buttons to Stop and Start containers

If you have ideas, suggestions or feedback related to the items above, or if you want to help, please comment below. Thanks! 😄

I was unsuccessful in running Servo on the VNC and in Cloud9. Please note, I tried downloading the packages from the Servo page.

Here are the errors:

error: XDG_RUNTIME_DIR not set in the environment.
thread 'main' panicked at 'Failed to create window.: NoBackendAvailable(XOpenDisplayFailed)', ../src/libcore/result.rs:785
stack backtrace:
1: 0x7f981b63eaaf - std::sys::backtrace::tracing::imp::write::h6528da8103c51ab9
2: 0x7f981b6466db - std::panicking::default_hook::$u7b$$u7b$closure$u7d$$u7d$::hbe741a5cc3c49508
3: 0x7f981b64633f - std::panicking::default_hook::he0146e6a74621cb4
4: 0x7f981a7f196a - util::panicking::initiate_panic_hook::$u7b$$u7b$closure$u7d$$u7d$::$u7b$$u7b$closure$u7d$$u7d$::$u7b$$u7b$closure$u7d$$u7d$::h1b136c5b997dba9d
at /home/user/servo/components/util/panicking.rs:45
5: 0x7f981a7f1829 - <std..thread..local..LocalKey>::with::h813eaa2cabd28878
at ../src/libstd/thread/local.rs:211
6: 0x7f981a7f16a6 - util::panicking::initiate_panic_hook::$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::he9b75ed68d2396bf
at /home/user/servo/components/util/panicking.rs:40
7: 0x7f981b62c3cc - std::panicking::rust_panic_with_hook::h983af77c1a2e581b
8: 0x7f981b646921 - std::panicking::begin_panic::he426e15a3766089a
9: 0x7f981b62dc3a - std::panicking::begin_panic_fmt::hdddb415186c241e7
10: 0x7f981b6468be - rust_begin_unwind
11: 0x7f981b67cebf - core::panicking::panic_fmt::hf4e16cb7f0d41a25
12: 0x7f981756bef1 - core::result::unwrap_failed::he361ed66efb41daa
at ../src/libcore/macros.rs:29
13: 0x7f9817568671 - _<core..result..Result<T, E>>::expect::h916c1c9ac8d3ac38
at ../src/libcore/result.rs:747
14: 0x7f98175650b0 - glutin_app::window::Window::new::h20f7c31a0a63b85b
at /home/user/servo/ports/glutin/window.rs:162
15: 0x7f9817564680 - glutin_app::create_window::hb54113b9ee251b02
at /home/user/servo/ports/glutin/lib.rs:48
16: 0x7f98174219fe - servo::main::h6924e5658370f6b5
at /home/user/servo/components/servo/main.rs:105
17: 0x7f981b645cb8 - std::panicking::try::call::h852b0d5f2eec25e4
18: 0x7f981b650b1b - __rust_try
19: 0x7f981b650abe - __rust_maybe_catch_panic
20: 0x7f981b64575e - std::rt::lang_start::hfe4efe1fc39e4a30
21: 0x7f98175505a9 - main
22: 0x7f98146ce82f - __libc_start_main
23: 0x7f981741f968 - _start
24: 0x0 -
Servo exited with return value 101

On both a Dell XPS 13 and a Chromebook Pixel, noVNC doesn't seem to propage mouse events (click, right click, drag) whereas keyboard strokes work fine. On a Thinkpad W540, both mouse and keyboard events work fine.

I suspect the touchscreens in both the Dell and the Chromebook. See also novnc/noVNC#510.

Currently, all machines on the Janitor are keyed to my own Cloud9 SSH public key.

To support users other than myself, the Janitor needs to:

• Let users add their Cloud9 SSH public key to their account.
• Provision user-specific environments with that specific key.

Currently, the Janitor only supports Debian-based development environments.

However, some of the large software projects that the Janitor aims to support (e.g. Firefox) also need Windows-based environments for development and bug-fixing.

EDIT: Progress on Windows support is currently tracked in https://github.com/JanitorTechnology/janitor/projects/4

STR

• Create a new Web project (e.g. Kresus)
• type the Janitor proxy URL without a trailing slash at the end: https://janitor.technology/UNIQ_ID/9876

Expected

This should hit / in the web app.

Observed

This returns a 404. The web app logs don't show any traffic to /.

If I correct the URL to use https://janitor.technology/UNIQ_ID/9876/, it works. I think it would be simpler for the users to allow the trailing slash or add it if it's not there. Jan tells me on IRC it might be an issue when the proxy and the web app are hosted on the same physical host.

When I trying to rebase code for Servo, I had trouble rebasing (and squashing) my changes.
The solution is inconvenient but is using sudo.

Solution:

To start sudo git rebase -i HEAD~yourNumberHere
** Rebase as usual here until about save **
To quit :wq!

I deleted the container, added it back, and it still won't open.

https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5/Constraint_validation#Constraint_API%27s_element.setCustomValidity()

"[Use] modern web capabilities to deliver an app-like user experience." - https://developers.google.com/web/progressive-web-apps

The Janitor should:

• be responsive: Fit desktop, mobile, tablet, or whatever is next.
• be safe: Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
• be linkable: Easily shared via URL and not require complex installation.
• have a manifest: Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
• work offline (#4): Enhanced with service workers to work offline or on low quality networks.
• stay fresh: Always up-to-date thanks to the service worker update process.
• send push notifications: Make re-engagement easy through features like (optional) push notifications.

@jankeromnes I was thinking of having a page that has a list of solutions for issues that get encountered when using The Janitor, perhaps a wiki page?

At the moment, when you want to contribute to janitor (through janitor), the docker host proxy will get confused, and use the same cookie and thus break the auth. This means that no static file will be served.

The current solution is to edit lib/sessions.js to change the cookie name on the following lines:

• janitor/lib/sessions.js

  Line 49 in 135c06a

  request.cookies.set('token', token, {

• janitor/lib/sessions.js

  Line 65 in 135c06a

  request.cookies.set('token', '', {

Doing this will allow you to run the janitor app using node app in the container's terminal, and access it on https://moz1.janitor.technology/<container>/8080/

If we were to use a random cookie name in those two lines, and store that cookie name in the DB for future uses, that should solve the issue.

In order to guarantee a consistent coding style, and prevent some types of coding errors to enter the code base, we should:

• Automatically lint the server code (Node.js)
• Automatically lint the website code (ES5.1 JS)
  • Handle every error argument, and every possible promise rejection
  • Use const everywhere possible, or let otherwise (only in ES6/server code)
  • Force null, 2 for every JSON.stringify call
  • Forbid empty lines between a function comment (e.g. // Do stuff.) and function declaratation (e.g. function doStuff (thing) { or exports.doStuff = function (thing) {)
  • Force an empty line below every if/else and try/catch block
• Automatically lint the HTML in /static/
• Automatically lint the CSS in /static/

Here are a few guidelines that I think should be respected:

• We should write very short but very simple code (no unreasonably convoluted code and no black magic)
• We should use explicit, full variable names (e.g. not c but chunk, not req but request, not values but durations etc.)
• We should sort most things alphabetically (requires, variables, parameters, HTML attributes, etc) unless it makes things more confusing

Here are a few tools we could use:

• eslint: A great JS linter, similar to JSLint and JSHint (we would need to write a coding style configuration for Janitor, or auto-detect it from our code)
• standard: Basically ESLint with powerful, pre-configured rules and no customization possible (it is opinionated but powerful and convenient. Maybe the most controversial rule it enforces is "no semicolons")
• flow: A static JS type checker made by Facebook.

I would be OK to enforce standard for Janitor, even if it removes all semicolons. @bnjbvr @nt1m @Coder206 @notriddle or @espadrine, do you have any thoughts or preferences about linting our code?

It would be very convenient to have the app restart automatically whenever some files change. I believe there's many different solutions that would do that out there.