Quick way to write JavaScript that requires babel and run it? - javascript

I want to write a JavaScript example and run it to see how something works.
The sample code might require a browser but not always. I'm open to two solutions, one that works with NodeJS, and one that is used for browser based code. In browser, I'm using React with class and other ES6 syntax including import/export which is not (yet) supported directly by node or node --harmony.
In Python, Java/Groovy, C/C++, C#, others, I could just run a command to compile the file and then run the executable (or just interpret the code), so I'm looking for something similar for JavaScript.
Conceptually, I would like to say:
dotranspile --out bundle.js main.js
node bundle.js (or firefox index.html, which loads bundle.js)
The key is that I don't want to have to create a webpack configuration file in every directory. I thought I found a command like this when searching one day, but can't find it now.
How do other people run javascript sample programs when babel/transpiling is required? I would also like to be able to save them for future reference (in some cases).
Currently, each time I want to write a test I create a directory with a webpack.config file, package.json, and use npm install, and npm run to run the code or start a NodeJS express server to serve index.html.
This seems to be a lot of overhead for a quick test, and it results in dozens of node_module directories with tons of files in them.

Maybe is not answer that you want, but you can always use jsfiddle with babel + jsx. I think that jsfiddle is very good tool for quick run simple app in babel/jsx or other libs, transpilers etc.

Related

How to run a node script by CLI custom command?

Currently, I'm working on a personal project and I'd like to create an alias for some commands that I have to run... Similar to:
jest ...
node ...
tsc ...
I think that for my project would be so helpful and cool to have something like
foo ...
I'm working with Node, Typescript, and JS.
I took a look on the internet and read saw some people teaching how to create some alias I tried and it works :)
I already have the alias working on my local machine cause I added the alias on the .bashrc file.
alias foo = command...
However, I also tried to put it on my package.json scripts section, like:
"scripts": {
"runFoo": "foo",
But when I run npm run runFoo it says that "foo" is not recognized... Are any way to do that? How the tools like jest do that?
I would be thankful for any direction about what to study for that.
Extra:
There is any way to run all the .js from a folder by using any node command without knowing the name of the files?
Like:
node *.js
It can help while I don't figure out how to do the alias...
Edit:
What I want to do is:
https://developer.okta.com/blog/2019/06/18/command-line-app-with-nodejs
The answer helped me to find this post, and following it, it worked here.
it says that "foo" is not recognized
That is because shell aliases do not work in npm scripts (they are only valid when directly called in said shell), see e.g. How can I pipe to a bash alias from an npm script?
Aliases are meant to reduce typing, and are not automatically shared across environments, on the contrary of npm scripts which are committed with package.json. Hence if you try running that script in another environment, the latter may not know that alias (or worse, use it for something else!).
How the tools like jest do that?
They do not... Their command is not an alias, but an actual executable binary or script.
When installed as dependencies, you will find links to their executable in node_modules/.bin/ folder, see What is the purpose of .bin folder in node_modules?
You can easily create such executable scripts, even written in JavaScript to be executed by a Node.js engine, see e.g. Appropriate hashbang for Node.js scripts

Is it ok to refer to node_modules directly?

The project I'm currently working on (Java/JSP) currently uses no package manager to manage its JavaScript dependencies.
The used libraries are just committed under version control, and referred as such from the JSP pages...
I would like to evolve to a workflow were we would use a package manager (e.g. yarn), and later on eventually also webpack to further optimise the build.
I would like to do this in a phased approach. As I have little to none experience with such a frontend workflow, I have some questions:
Would it be weird to just start with defining the used libraries in a package.json file, and use yarn to manage to package?
yarn will then fetch the modules and store them in the node_modules folder.
Is it bad practice to refer to the scripts in that node_modules folder directly from within the JSP files?
Example
package.json:
"dependencies": {
"jquery": "^3.4.1"
}
app.jsp:
<script src="node_modules/jquery/dist/jquery.min.js"></script>
Yes, that's completely ok. It's the way we normally initialize frontend projects (probably sometimes, some higher-level script does it for us but still). Just run npm init.
Oh yes, that's quite bad. Most probably, it simply will not work. If you want to load something directly on a page, you need a cdn version.
To be honest, having a package.json is not that useful without a building tool like webpack, gulp or grunt.
UPD:
Regarding why loading things directly from node_modules might hurt:
A lot of modern JS packages (like, for instance, React) use modules that are not implemented yet in any browser or ES5+ syntax which is supported only by some browsers.
This way, you may load React directly but it will crash in any browser with something like import is not defined.
Basically, a lot of modern packages expect you to either have a building tool or use cdn version.
Honestly, I don't know how many packages let you seamlessly load things directly from node_modules.
So, in your particular situation, I'd say that if particular packages you use let you do so & are shipped with browser-compatible version, you can just go ahead & do it this way.
Nevertheless, I see it highly possible that sooner or later you will face a package that will not let you to include it this way (or worse: it will, but will crash some browsers that don't support latest JS features/introduce other nasty bugs in your app).
Hopefully, at this stage, you will already have the building tool configured.
Bonus:
Relatively recently some browsers started to support modules!
There are even tools like snowpack that do something particularly similar to what you are looking for.
Even though, you still need to be very careful with this. Direct inclusion of lodash.js, for instance, will generate 640 GETs (check out this article -> "Libraries" section).
NPM packages are meant to be run with Node, not in a browser. You would need to serve a browser-friendly version, using something like webpack or browserify.

Compile Dlib for webassembly

I am trying to build dlib for webassembly using emscripten but I am not sure how to do so.
Currently, dlib generates executables and not bytecode which is needed for emscripten. Is there some way to get around this issue?
Currently this is what i am doing (from within the dlib-19.4 folder.
cd examples
mkdir build
cd build
cmake ..
emmake make
for the next step, I need to input a bytecode file however, dlib seems to just generate executables which the emcc command will not accept.
From what I can read from Dlib's documentation is that it has a lot of features that emscripten does not provide including threading and so on. So you will need to exclude functionality thats not supported.
Also referring to How to Compile section, it mentions how to use Dlib without Cmake.
It has a simple gcc example for SVM.
You should probably use this approach ie include the appropriate dlib headers in your project, write your functions and expose them for emscipten.
Then after building the js file you should be able to call the "exposed" functions from JS.

Load remote scripts with browserify

I really like using cdnjs to load up javascript on the client-side, it makes my project smaller and cleaner, and loads everything faster as well. I currently use require.js for module loading, which can load from cdnjs and shim traditional scripts to work with it easily. I've been looking more into browserify recently as an alternative, and while I did find browserify-shim, which can shim non-cjs modules much like require does, I'm curious if there is a way to load a script from a remote source with browserify, or if you have to install everything locally no matter what.
If the answer is that you would have to install everything locally through npm, this makes things a little weird. On one hand, you can add node_modules to the .gitignore file and not have to worry about keeping all the deps on version control if you are using a package.json, but on the other hand, you'd need to get the modules back in there on deploy, which means an additional post-deploy step that would run npm install and that node would need to be installed wherever you are deploying to, which also seems a little awkward to me for a static site especially.
Really, any ideas or discussion on this would be great : )
The way I think about it is this, you have three options: concat the JS files together locally (browserify) before deployment, load them in real-time (require.js), or a mix of both. To be fair, you can use require.js to concat your files with r.js too. For me at least, I like how browserify is designed to use the same syntax and mentality as npm modules. I think in the end the weirdness your experiencing doesn't really matter. If all the code is packaged together, you deploy, and there aren't any dependencies, seems like a win to me. Also, I think this is more in line with Java and similar compiled languages are doing, which is putting all the deps together in a deployable package. I know I mention Java but don't let that scare you because really we are all benefitting from the ideas of those around us even the languages we think we don't like. If I had to bet my money, I would bet on browserify since it's offering (what I consider) to be a more mature means of handling modules (organized by file based rather than syntax). The npm also gives us a great way to share our code so two thumbs up for them.

Use "coffee" instead of "node" command in production

I have an app.js that is running express.js.
I wanna convert the code to coffeescript and thought about to create a app.coffee that I compile to app.js so I can run it with "node app.js".
But then it hit me that I could just write that file in app.coffee and run it with "coffee app.coffee".
Is this a better way? Can I run the server with "coffee" in production?
Yes you can use coffee command in production. I use it.
I can see two reasons why you would want to use app.js wrapper.
You want to use local installation of CoffeeScript. (different versions between apps)
You want to use the default npm start to launch your server :) See npm help scripts
Oh, and you don't need compile it. You can use a wrapper like this which compiles the coffee file transparently:
server.js:
require('coffee-script').register();
require("./yourcoffeeapp.coffee");
This wrapper technique is especially useful if you want to use CoffeeScript in some hosted environments that does not directly support the CoffeeScript command. Such as Cloud 9 IDE. No need to fiddle with compiled js-files.
I upvoted Epeli's answer, which is clear and excellent—using a .js "wrapper" rather than the coffee command saves you from potential path headaches—but since this is a subjective question, let me throw in a contrary opinion.
Many CoffeeScripters, myself included, recommend compiling non-trivial Node apps to JS before deployment. It's not hard—look at Sam Stephenson's node-coffee-project template, which includes a Cakefile that makes compiling and testing a breeze.
One major reason for doing this is that Node stack traces give line numbers that refer to the compiled JavaScript, not the original CoffeeScript. So when errors are recorded in your server logs, it's nice to be able to look at the corresponding code right on the server.
Another advantage to compiling to JS is that it lets you work with more tools on the server—many Node debuggers, testing frameworks, and amazing goodies like cluster like to operate directly on .js files.
Getting a good compilation setup for your project takes some work, but I think you'll find it worthwhile.
I prefer to create main.js like this:
require("coffee-script");
require('./yourcoffeeapp');
And yourcoffeeapp.coffee like this:
http = require 'http'
on_request = (req, res) =>
res.writeHead 200, {'Content-Type': 'text/plain'}
res.end "Hello World\n"
server = http.createServer on_request
server.listen 1337, "127.0.0.1"

Categories

Resources