Add docker-compose for development

[pmzi]

Hi,

This PR will add a docker-compose.yml for local development. It is best if anyone could see their application right inside the OSJS when they are developing their app, and changes were live. So I added a docker-compose to achieve so. Also, everyone can see a demo of others' apps with only one command (docker compose up).

[pmzi]

@andersevenrud

[andersevenrud]

I think maybe it would be nicer if there was some kind of CLI command available that could do something similar to this for you, except using the already provided distro code etc.

So one for example could do: npx osjs-cli dev:package username/reponame (or an URL) and it would:

• Clone into the src/packages directory (alternativelly download archive)
• Run discovery
• Perform any required npm commands
• Then spawn the watch command for the package
• Let the user know it's running and to restart the server (or maybe we can even start a server here)
• Here it would be possible to even fire up a browser tab
• And here I think it would be cool if it was possible to add something to the URL so the given app was started automatically (no configuration required)

This way the entire process is pretty straight forward:

git clone https://github.com/os-js/OS.js.git
cd OS.js
npm install
npm run build
npx osjs-cli dev:package pmzi/some-application

(heck, the npm install and npm run build could even be put into a one-liner in package.json to make it even simpler).

[andersevenrud]

The reason I'm suggesting a solution like this is because the process of installing a package for viewing (especially if prebuilt or distributed on ex npm) or development purposes already is relatively simple. And if the idea is to simplify it even more, then some kind of automation is the simplest solution and does not require to add anything into the packages themselves (which means more maintenance and chances of breakage).

It's possible to do this inside Docker as well, or even provide a way to quicky run a demo of any app by doing for example:

docker run --rm -p 8000:8000 osjs/osjs username/packagename

This just does the steps described above. But for a development environment then using the provided distro is pretty much the way to go :)

[pmzi]

Hi,

Thanks for the response:)

I do agree with the overall idea of adding a command to osjs-cli, but I don't like the first solution you offered. Generally, when I want to run a package and see a demo (or start the development environment), I expect it to be done inside the package which is being developed. For example, when I am inside the pmzi/osjs-example-package, I expect to run some command like npx osjs dev:package rather than going to clone the osjs itself and then running some command there.

What I want to propose is sth like this:

1. When I started a project (sth called pmzi/osjs-example-package), I should be able to run the package inside the osjs environment by executing npx osjs dev:package.
2. After executing the command, the osjs project will be cloned into some folder called node_modules/.osjs (for example).
3. After that, the current package will be copied into node_modules/.osjs/src/packages and the related commands (like package:discover will be executed.
4. At the end, the osjs cloned inside the node_modules/.osjs will be started on port 8000.

The above instructions are pretty straightforward and can be done by only executing one command: npx osjs dev:package.

If you agree with the general idea, I will start working on it in the osjs-cli repo.

[andersevenrud]

One drawback to your suggestion is that you'll end up with a lot of osjs installations (hence lots of node modules). Also, copying things into node_modules is generally a bad idea, because it's volatile.

Just a note; it's possible to define custom discovery paths.

rather than going to clone the osjs itself and then running some command there.

But this is what happens in your step 1, isn't it ?!

---

The idea behind the "distro" repo as I call it is to use it as an environment for everything. If it's configured to run as a monorepo you can have a single source of node_modules for everything, also with workspaces in a monorepo it's very easy to run scripts in parallel (though requires a tool).

Though, I definitely see the value of being able to spin up almost like a sandboxed environment for package development.

So maybe there's a solution in the middle of both of the suggestions.