search

musictheory / NilScript

Objective-C-style language superset of JavaScript with a tiny, simple runtime
Other
50 stars 5 forks source link

Allow a file to override existing classes #53

Closed IngwiePhoenix closed 9 years ago

IngwiePhoenix commented 9 years ago

I just realized, that I have an issue in my loader for WebPack: When the file is changed and re-compiled, my loader returns an internally cached source, thus otherwise re-using the existing compiler-cache... So even if I update my file, the changes are not reflected unless I force-reload the module, thus whiping the internal cache and forcing a fresh rebuild.

Since I want to allow the squeeze option, I thought I should keep the compiler state, and return a pre-cached version...guess this method does not quite work. Can you recommend an alternative way to go about this?

https://github.com/IngwiePhoenix/oj-loader/blob/master/index.js#L28-32

iccir commented 9 years ago

Can you use webpack to keep track of the dependency tree for all .oj files, and then pass the concatenated version to ojc when any of them change?

IngwiePhoenix commented 9 years ago

Sadly not. All I can do is create the list of files myself. The way it works can be seen here:

1 http://git.ingwie.me/ingwie/bird3/blob/master/web-lib/main.oj http://git.ingwie.me/ingwie/bird3/blob/master/web-lib/main.oj

2 http://git.ingwie.me/ingwie/bird3/blob/master/web-lib/BIRD3App.oj http://git.ingwie.me/ingwie/bird3/blob/master/web-lib/BIRD3App.oj

The resulting file is actually a combined version of all files together, the require() call being replaced with an internal loader. So the build itself is dynamic. Currently, the online version of my demo uses UglifyJS to press down the size of the script. Otherwise I could’ve shown you. :)

The process is, that WebPack first sets up it’s own version of a require() function plus resolver. The resolver is aware that .oj files should be processed with my loader. The loader gets the source, processes it to plain JavaScript and passes that source - and eventually plus a source map - back. The JavaScript is then added to the webpack - and when the pack is run, the code acts as if it was require()’d. In my case, I use a .oj file directly as the entry, and am working on an application class. This whole setup is still very new, but I am planning to develop a front-end library using OJ that is based off jQuery, so i can merge commonly used functions in my app - such as emitting events to socket.io - into a single, simple interface.

1 is the main script that sets up the base, whilst #2 contains the application class.

Therefore, I have to either build the file list on my own, or I have to find another way. WebPack provides a file watcher interface, that can re-compile my bundle on-demand. So if I publish a code change, it can re-create the bundle right away.

IngwiePhoenix commented 9 years ago

I managed to fix my issue with the compilation. The current oj-loader works veeeery flawlessly. And as far as I know, ti is the ONLY "Objective-X" loader that there is. ObjJ still struggles with a NodeJS port, while I already have this working just fine. :)