René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Compiler CLI and Scalability","articleBody":"This document proposes to replace/(enhance) the `racks` tool currently used to compile RacketScript programs.\r\n\r\n## Motivation\r\n\r\n### `racks` is slow\r\n\r\n- It compiles each file serially, which is particularly frustrating during first compilation.\r\n- We did some work to avoid recompiling unchanged modules, but it still not foolproof and may require full recompile under certain circumstances. Eg. If a module with macro changes, any other module using that macro must be recompiled.\r\n- The identifier graph used to follow the bindings is recomputed in each run, which takes noticeable number of seconds. This graph can potentially be cached, and only affected modules should be processed to update this graph.\r\n  \r\n### `racks` is impractical\r\n\r\nIt simply compiles what it gets. It has no notion of `package.json`, `info.rkt` which is often used in practical applications. It overwrites `package.json` with the default one.\r\n\r\nSome common examples:\r\n\r\n- User can't specify JS dependencies at all.\r\n- No control over how to produce the distribution JavaScript file, and limited to what we allow to use e.g. Gulp, Babel, Minifiers ...\r\n- Plain JavaScript files has to be copied manually to distribution directory.\r\n  \r\n## Proposal\r\n\r\n`racks` should be replaced with a tool that more or less is like what `raco` is to Racket or `lein` is to ClojureScript. Here's a rough workflow I see:\r\n\r\n\r\n- Create a new project:\r\n\r\n\t\tracks init my-new-project\r\n\r\n- Install all dependencies:\r\n\r\n\t\tracks install\r\n\r\n- Create a new project using some a template project structure. However, unlike current situation, this is used just to create project. The config can be edited to whatever.\r\n\r\n\t\tracks init my-new-project -t babel-webpack\r\n\r\n- Builds the project:\r\n\r\n\t\tracks build\r\n\r\n- Watch the project and build automatically:\r\n\r\n\t\tracks build --watch\r\n\t\t\r\n- Start a REPL\r\n\r\n\t\tracks repl\r\n\r\n\r\nAll these command could be simple `raco` extensions, like `raco racketscript \u003csubcommand\u003e`, and `racks` can just be alias for `raco racketscript` or something like that.\r\n\r\nSecondly, compilation of each module should be independent of other module as much as possible. There is only much we can do here as mentioned earlier, but there is still scope.\r\n\r\n`info.rkt` can act as combined project configuration, i.e. for both Racket and JavaScript. Since, `package.json` is simply a JSON, it can just be a S-expression in `info.rkt`. The project config can also specify the main entry point, any additional JavaScript/static files that needs to copied, or pretty much anything user may want to do pre/post operations.\r\n\r\n\r\n## Conclusion\r\n\r\nThe documents proposes much more than what we have currently have time and resources for. However I believe it is certainly something we should start thinking about. I will keep on updating this document based on later discussions.\r\n\r\nThis shouldn't require any changes to existing compiler or runtime, and can be built as a new script. So, while we slowly work on it, it shouldn't block us with any other tasks in hand.\r\n","author":{"url":"https://github.com/vishesh","@type":"Person","name":"vishesh"},"datePublished":"2017-09-12T07:25:54.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":6},"url":"https://github.com/131/racketscript/issues/131"}