I'm running a node web server via "coffee my_server.coffee", and I load dependencies via
require './my_library.coffee'
My codebase is pretty big, and it's starting to take a significant amount of time for my server to start up, which I believe is due to coffeescript compilation... when I convert the entire thing to javascript, it loads much faster.
What's the least painful way of caching the compiled javascript, so that when I restart my server it only compiles files that I've edited since I last started it? Ideally it would be totally transparent... I just keep on requiring the coffeescript and it gets cached behind the scenes.
Alternatively, I could run "node my_server.js", and have a watcher on my directory that recompiles coffeescript whenever I edit it, but I don't really like this idea because it clutters up my directory with a bunch of js files, makes my gitignore more complicated, and means I have to manage the watcher function. Is there a way for me to have my cake (running the "coffee" executable and requiring coffee files) and eat it too (fast load times)?
Well if you don't want to "clutter up your directory with a bunch of .js files", I think you're SOL. If you don't store the .js files on disk ever, you need to compile .coffee to javascript on the fly every time. The coffee command to my knowledge does not do any comparison of mtime between the .js and .coffee files, although in theory it could, in which case leaving the .js files around could help your situation. Given your preferences, the only thing that I can suggest is:
run a watcher that builds all your .coffee files into a separate build subdirectory tree
start your app with node build/app.js instead of coffee
ignore the build directory in your .gitignore
You'll have to give up on running things via coffee though. Curious to see if others have better suggestions. My projects don't suffer from the startup time issue. SSDs and small projects help to keep that short and not annoying.
Related
I have an emscripten/webassembly wrapped C++ class that launches and uses pthreads internally. It generally works fine when used in javascript on Chrome in its stand-alone development sandbox. However, I can't really get it to work with create-react-app and webpack (i.e. I used react-app-rewired to be able to configure webpack).
The problem seems to be from the complexity of the javascript and wasm files that a threaded emscripten build creates, and the confusion those scripts have due to the renaming of files that webpack produces. The files produced for a multi-threaded emscipten build are:
MyModule.js
MyModule.wasm
MyModule.worker.js
I can (I think) get it to work in the non-threaded mode where there is just a MyModule.js and a MyModule.wasm file through the use of the Module's locateFile method. However, the system gets very confused due to the introduction of the new MyModule.worker.js file which the MyModule.js file launches on its own within a WebWorker. And of course the MyModule.worker.js file needs to also find and get access to MyModule.wasm, and that gets lost too (i.e. can't find the right file name due to the webpack renaming).
Anyway, I've spent hours searching the web for any successful use cases like this, and trying may things, including manually editing the MyModule.js and MyModule.worker.js files, but without any luck so far.
Has anyone successfully tried something like this, or any other advice on getting a multi-threaded emscripten/wasm build to run properly with webpack (or create-react-app)? Any advice would be greatly appreciated.
NOTE: This question isn't about running a emscripten/webassembly module in a web-worker thread (although in the end I'm going to run all this in a web-worker). Its specifically about a multi-threaded emscripten build (i.e. C++ with pthreads) launching and running properly with webpack.
In Module's locateFile, you should return the correct path for MyModule.wasm and MyModule.worker.js.
Besides, In Module's mainScriptUrlOrBlob, you should assign the path for MyModule.js.
The mainScriptUrlOrBlob is used in worker for loading the wasm.
I am building a plugin for my website that should do some antispam (primarily educational reasons).
It has mostly been finished but now I am now hitting a massive speedbump in the final bits before I want to start doing "live" trials with it.
You see, I have published the plugin onto Packagist but the problem is that Packagist only takes what is in the repo but doesn't take the assets that I roll out of my pipelines in the form of artifacts (which is the final JS that the client can understand and use).
Without this, however, the plugin cannot work.
But in my experiences, compiling the code on my local machine and then manually committing it to Git is a huge pain and caused a lot of errors in the past (because sometimes I would forget to commit the JS, sometimes I would forget to commit the TS, or I would forget to recompile it all etc. etc.).
In this case, Typescript, however, is somewhat interchangeable with things like SCSS (basically any front-end asset that still has to be compiled somewhere).
So my question is how I would go about this, because obviously, I don't want to just go and tell people that want to use this plugin (I try to build code assuming they are): "yea, you can use it but you are going to need to setup a typescript compiler and everything regardless if you are going to make changes to the plugin".
I'm looking for a way to deliver a node.js server-side application (not browser) as a single file that contains all my code and node_modules. Well, it can be a few files, but I'd like to avoid shipping 10,000+ files, that are usually in node_modules.
I've used solutions like pkg, but I don't need an executable that has node.js bundled. I'd rather ship node.js separately and only have a bundle with code. This would be especially useful as I need to ship a few applications and don't need each of them to contain a copy of node.js.
Appreciate any suggestions.
I'm just starting to learn Angular, I installed in my Ubuntu Linux:
Angular CLI: 7.1.4. and
Node: 10.14.2.
My question is, why one project is too large? I mean a simple "helloworld" is 334MB, I don't know why, Is it possible resize it? or delete any folder that is unnecessary? Or Is there something wrong with my installation? (how can I detect that?)
The bigger folder is node_modules, and when I create my projects, generates a lot of folders.
I was reading about "angular lazy loading", but I'm new.. It is not totally clear for me.
this is the folder spaces:
Please... I hope somebody can help me...
best regards
You might be using big bundles which are not needed, so you can break them up:
https://medium.com/#julienetienne/javascript-bundles-are-too-big-break-up-the-libraries-3be87d5ef487
In modern JavaScript, projects require modules that themselves require modules that require modules... resulting in node_modules directory with hundreds of dependencies. A 100Kb library might be included because someone needed one function from it. JavaScript is not compiled, so all that source tends to be rather big. This is an unfortunate, but unavoidable truth; your Angular project directories will be big, and there's nothing you can do about it. It is perfectly normal.
The good part: modern JavaScript deployment typically includes packing up those libraries with Webpack or Parcel or similar code bundlers. Most of them implement "tree shaking", which analyses the code to find only the functions that are potentially utilised starting from the entry point, and only bundle those, ignoring the rest. This means that 100Kb library whose one function is used is transformed into just that one function in the final distribution bundle.
Not all of the bundlers are equally good at it at this point. For example, Webpack cannot tree-shake the CommonJS modules, only ES6 ones.
You can remove node_modules folder when you are not going to use the app.
And, when you need work on the application, you can re-generate node_modules using the command: npm install
Those are just node-modules, they are needed for building the project, but not necessarily everything inside of them will be deployed to production. As Amadan said, there is a process of tree-shaking (filtering only used modules) and also in production you use the minified version of the same JS code (where for example whitespace is missing and variable-names are shortened), among other optimizations. A production-optimized Angular project should not be more than a 100KB for a hello-world application.
In the provided image I see packages like
selenium-webdriver
protractor
Those belong to dev-dependencies (see your package.json file) because they are used for testing. When building for production, no code from dev-dependencies should be included. The typescript package (which is nr.2 in size in your screenshot) will also not be present in production because types like string are only used for writing Typescript code, but the browser receives Javascript, which it is compiled to.
I have a lot of files in my assets/js directory. At first I thought I was somehow losing the ability to see/serve files from sails. But after I let sails run for a little while, it seems sails found my files in the assets/js directory and I was able to run my intern tests. I'm assuming there is some type of behind the scenes cache going on that must run before I can successfully make a request. Is this the reason, and if so, how can I disable it for a more instant access to my files?
Sails.js needs to do several things before lifting the server, you can try sails lift --verbose to see what's happening.
Also, if you dont mind, take a look the .js files under tasks/config/, Sails.js uses them to link/copy/build assets before starting.