Turn bin/build into a command line tool

[TechplexEngineer]

rather than having a number of different tools to satisfy all the build requirements, bin/build should have flags added to satisfy the different needs.

Here is a list of functions:

• Build all
• Generate language file #261
• Convert old style language plugins to the new style Add functionality to bin/build to convert old language plugins #268](Add functionality to bin/build to convert old language plugins #268)
• clean (delete all files generated)

[TechplexEngineer]

Hey @dethe, I was just writing a Makefile here at work, and though that would really be the way to do this.

I'm not sure if that would limit any of our windows friends, but I'll throw one together for kicks.

[dethe]

Hi @TechplexEngineer, did you ever make progress with your Makefile?

[TechplexEngineer]

I never got the Makefile working.

[dethe]

It would be nice to make bin/build be a npm run command like documented here: http://www.substack.net/task_automation_with_npm_run

[CelticMinstrel]

That page seems to be assuming server-side javascript. Maybe it could still work on client-side, I dunno.

[dethe]

@CelticMinstrel We're talking about server-side (well, command-line) tools for building, linting, validating, and minifying files. Not expected to work client-side.

[CelticMinstrel]

I didn't think Waterbear had any server-side stuff...

[dethe]

When you run bin/build it runs locally on your machine. That's what this is about. Not server-side so much as command-line.

We're also implementing server-side code for Persona logins and for using Node to talk to other systems (like Minecraft), but that's a different issue.

[dethe]

Options for parsing the command-line:

https://github.com/chevex/yargs
https://www.npmjs.org/package/minimist

[CelticMinstrel]

Yargs looks quite nice.

[dethe]

README for updates to bin/build and file layout

Goals:

• Don't have to rebuild files for each change, can run out of the box in dev mode
• Able to build in staging mode (files all concatenated) or prod mode (files concatenated & compressed) (Build: command for staging version of code #735)
• Able to jumpstart a new language wrapper with a command (Generate new language.html file from a command #261)
• Able to lint CSS, JS, and menu files (Made ajax.js a little easier on the eyes #584)
• Support multi-line script templates (Support for multi-line script templates #684)
• Move towards supporting functions in block definitions (not just script templates) (Support script function vs. script template #726)
• Group all language-related files sensibly
• Don't check in generated files (as much as possible)
• Start a webserver with a command (Have command to start a basic webserver #731)
• Build only a subset (one language) rather than everything when rebuilding (Build: command to only rebuild one language, not everything #736)
• Build custom runtime html as well as ide html
• Support running in a non-root directory (fix for Examples don't load if waterbear is not in the root folder #403)
• Move language config out of bin/build, make it more generic
• Check that all linked files actually exist (warn if missing?) (Build: don't add includes for non-existent files #737)
• Check that all existing files are linked (warn if missing) (Build: warn for existing files that are not linked #738)
• Move stage & examples to config. Stage can be two-part: runs in browser or not (Build: move stage and examples to config.json #739)
• Move runtime support to config (i.e., should runtime files be included in build step for language?)

Steps to get there:

• Move [language].html -> languages/[language]/index.html
• Point links in index.html to new locations for languages/[language]/index.html
• Move iframeRunner.html -> languages/[language]/runtime.html
• Move examples/[language]/* -> languages/[language]/examples/
• Move languages/[language]/* -> languages/[language]/blocks/
• Move languages/[language]/blocks/[language]* -> languages/[language]/
• Move template/[language].stage -> languages/[language]/templates/stage.html
• Move template/[language].examples -> languages/[language]/templates/examples.html
• Move languages/[language]/[language].js -> languages/[language]/ide.js
• Move languages/[language]/[language]_runtime.js -> languages/[language]/runtime.js
• Move languages/[language]/blocks/[plugin].js -> languages/[language]/blocks/[plugin]_ide.js
• Move languages/[language]/blocks/[plugin].json -> languages/[language]/blocks/[plugin]_blockmenu.js (pre-wrap in wb.menu() call)
• Move wrapper code from javascript wb.wrap() to runtime
• Tighter definition of what is needed for language ide, which methods need to be implemented/overridden (Define requirements for a language wrapper #733)
• Take advantage of custom runtime.html to simplify interactions between ide and runtime and simplify runtime loading (When running a script, be sure previous script is fully cleared #734)
• Fix problem with reloading script without clearing previous script
• Add support for runtime CSS (in config.js, bin/build, and templates) (Support runtime CSS #732)

[stretchyboy]

Not sure about "Not having a stage also implies not having _runtime.js files" I was thinking about using the runtime files for waterbear specific wrappers for libraries but haven't needed one just yet.

[dethe]

Good point, maybe better to keep stage and runtime explicit and not have one magically include the other.

[dethe]

Up until now, all runtime files were Javascript, but @nosman raised an interesting issue because he wants to include Scheme runtime files for his scheme-in-browser blocks. We should add support for non-JS runtime files.

[dethe]

I've got most of the remaining work in separate issues. If I've missed anything, feel free to create another issue. Going to close this umbrella issue and track the rest under their own, smaller issues.