search

lihaoyi / workbench

Tooling around scala-js
234 stars 56 forks source link

feature: allow embedded server to define "get" directories to create virtual filesystem #7

Closed aappddeevv closed 10 years ago

aappddeevv commented 10 years ago

I'll try to create a pull request but I wanted to document this feature here.

This would work in the same spirit as sprockets. It looks like the spray server is being used so getting access to the server should allow you to add your own "get"s.

Motivation: When developing web apps, you may have many assets strewn about your filesystem or directory structure. You want to use the final path structure in your files (links and scripts). A virtual filesystem creating by mapping "gets" should allow you to do this for development purposes. This would would work regardless of the IDE you are using and whatever resource management it performs.

lihaoyi commented 10 years ago

I don't really understand. What's a sprocket and what's a "get" and how do they relate to workbench? Are we talking about customizing the files we watch for live-reloading?

aappddeevv commented 10 years ago

sprocket is a ruby-based dev tool for the web world. It also sets up a webserver during dev so it can serve up files. It is also a packager, but that's not the part that I am referring to. (note: https://github.com/sstephenson/sprockets).

Workbench does 2 things. It watch files for changes to do live reloading. It also creates a webserver to server up assets of course. I don't think workbench is trying to be a general purpose tool, but a small addition of allowing you to map some filesystem directories to a web path, allows you to use workbench to more easily serve up other web assets needed by a web application.

Example: in addition to a js directory you may have in your local folder for dev for some javascript, you may also keep bower managed js packages on other paths. At some point, you'll do a final packaging into the web application hierarchy but during dev, you will keep different assets in different locations. But you want your dev html files to not have to use the dev paths (e.g. when you load a script) but the final path location of your packaged app. Another example are the scalajs generated js files. Any html that uses them typically will have a very specific path.

Since workbench intercepts the /workbench.js get request, something similar, where you can map a list of directories and have them map to a specific request path as well, would allow you to keep those assets in place. The other part would be to allow a specific map request, say to the "name" of your project to automatically concatenate the three scala-js generated files. So when you pull your .js file in through a script tag in your html, it pulls in the extdeps and intdeps (all concatenated) as well.

Benefits: Automation to rationalize the paths in your html files as you develop your application. This also simplifies using scalajs as part of a larger web application.

lihaoyi commented 10 years ago

So it would basically allow you to customize the assets it serves and the assets it watches to trigger reloads? I'm reluctant to add too much complexity, but that seems perfectly reasonable.

aappddeevv commented 10 years ago

That's it. The scala js tree will usually be either used by itself to create a package such as for bower or be overlaid in a grunt/bower/some other main build system tree that can build a dev or prod tree. In this case you need to watch different non-sbt related folders for change either on the original asset folder or the transformed asset folder. For dev it would be good to also be able to map a folder to a specific URL root as well so you could simplify and standardize the URLs embedded in your HTML files e.g. Mount the sbt target output folder to the URL /js.

lihaoyi commented 10 years ago

Closing for now, since I don't have the time or inspiration to do it. Feel free to fork it and prototype something and send a PR if it turns out well =)