We Keep Coding

How many times a TypeScript file compiles?

I want to study typescript and start to build my idea by using MEAN technology stack but I am afraid that typescript needs to be run every time a user enters the website or it is only one time?

You build your project once using the TypeScript compiler and that produces .js files that can be run directly in nodejs or the browser (depending upon which environment they were designed for).
This is one-time process. From then on, the only code that actually "runs" is the compiled output .js files.
So, NO TypeScript code does not need to be re-compiled every time a user enters a web-site.
Your code would typically be recompiled only when you modify it and wish to "build" the newer version of your code.

Typescript compiles to JavaScript when you run the ng build and it also optimizes codes. After build completes you will have an index.html plus .js files that each one is generated based on one of your lazy loaded modules.

Organising a client & server SPA/Node.js application

I am writing an application with a Node.js backend and a single-page web app front-end.
I am keeping the client and server logic in the same project for simplicity and speed of development.
I am considering how best to organise the artifacts.
The Node.js part is straightforward because it doesn't need to go through a battery of pre-processors (transpilation, minification, concatenation etc).
The front-end needs to be transformed per the above, and I guess placed in a dist folder.
The current hierarchy of files is like so:
my-app
- src
- client
- server
Should I put the dist folder for the client artifacts under src/client?
Has anyone tried this and found problems with this approach?
I am using Heroku (a deployment system that uses git).
Committing the built artifacts for the client feels wrong, but if I want to deploy it by pushing to Heroku I think I need to commit them. Is this correct?

This question, as is, invites opinionated answers, so I'll start by saying this is by no means the only way to go, but in my opinion, it is the easiest to work with and makes the most sense.
The production client code, after pre-processing, should be located in my-app/dist or my-app/dst, which could either mean distribution or destination, depending on how you look at it. Either way, my recommendation is to commit this folder, as it saves you a lot of hassle debugging remotely.
For example, if your code works locally but not remotely, using something like the postinstall hook to generate your dist folder adds yet another suspect to check when trying to determine what the issue is with your program.
Another advantage of committing the dist folder is it allows you to specify all the packages you use for your build process as devDependencies rather than dependencies. This is a huge plus, and makes deployment a lot faster, as well as less memory usage on your heroku process.
That being said, I still recommend (as you already probably plan to do) using an automated watch task to build your dist folder for ease of development, even if you decide you don't want to use that same build process remotely and opt for committing the dist directory instead. You could add that as a custom npm command, e.g. npm run build and have that invoke your gulp task.
One last thing. For those of you using templating languages like pug or dust or ejs instead of a framework like react or angular, I recommend determining whether you can run any of your templates to build static HTML files that will be served in production.
If not, you should at least compile your templates (not to be confused with running them) by following the recommendations provided by your particular templating language. Typically, they'll suggest using their command line utility to generate the compiled templates, so that they don't have to be compiled every time they're invoked in production. This will make your node.js server respond faster to requests at the expense of using more memory to cache the compiled templates.

If you're planning to go this route, I would edit nodejs app.js/index.js to serve static file and point the directory to dist/.
Also, you would need to tell express to forward all non-api requests to the frontend.

How make deployment onto Amazon Web Services (AWS) with ReactJS/NodeJS together?

I currently have ReactJS + NodeJS/ExpressJS + Webpack onto EC2, Amazon Web Services (AWS) under one project and would like to get it deployed together at once, in one project.
What are some suggestions on how to go about doing so? Done the research, and I've only seen tutorials on deploying one in specific, whether it be just ReactJS or just NodeJS. Any insights or leads would be greatly appreciated.
Will accept/upvote answer. Thank you in advance

You don't "deploy" ReactJS, it's just a static file or files like any other JS libraries in your applications. You also don't deploy Webpack. Webpack should run on a developer machine (or in CI/CD stack or build system).
As for the NodeJS part just use Elastic Beanstalk.

I do not commit builds to source control. I see that a lot and it can make things easier, but you can also forget to rebuild as you have to do it manually, and it adds a lot of bloat to your repo.
I believe builds should be run as part of the deployment process. Assuming you are using git, you can add script hooks/post-receive in a remote repo there. When you push to that remote, the script will run. This is where I do my webpack build.
You may want to look into https://github.com/git-deploy/git-deploy for context, but I do this manually.
In my projects, on the deployment machine I do git --init --bare /var/git/myproject.git then add the script in /var/git/hooks/post-receive. The hook checks out the code into /var/www/myproject, runs the build, which fills in the /var/www/myproject/build. Then it removes the old /var/www/myproject/public and renames build to public. And done.

I'm coming from more of an operations background and would say that if your goal includes keeping that site up as much as possible then use Packer to generate AMI's and CloudFormation to build an Application Load Balancer (the newer, cheaper brother of ELB) in front of an AutoScalingGroup which keeps the EC2 instances up and running.

I'm currently working on a large scale project doing exactly what you describe. First off, there are so many different ways to do this, so what you really need is some general guidelines to get started, then we can dig a little deeper into details when some initial decisions are made, if you'd like. If you've already got the app deploying and running in two separate steps, but are just looking to combine those, I can definitely help. I'd just need to know how you're currently building/deploying. If you're just getting started on building your pipeline and need to set up the process from scratch, then read on:
First off you'll want to set up some kind of build server that will install your npm dependancies and run your webpack build. Most likely you'll want a separate webpack config that's just for your build server, this'll give you a build optimized for production or qa/staging environments. This config should split out vendor files that you won't update all the time, pull out seperate css files with extract text plugin and uglify the files. If you have an isomorphic React app, or are using es6 features not supported in your version of node, then you'll need a webpack build for your server code as well. This is really different from the hot reloading build you'll want to have on your local machine while you're actually coding the app. I'll be happy to show some examples if you'd like of our webpack config files for both local development and our CI build. You may also need a build.sh or makefile to do something with the compiled .js files that your webpack build creates, but that'll depend on your deployment which I'll cover later. You can run your production build locally as your getting your config just right and fire up the app from those files to test it's all working. Additionally, since you'll likely want to be able to automate all of this, you probably want to run your tests and linting right before you build your app, we run eslint and mocha/jdom to run our enzyme/expect specs as part of our build. Once that's all working nicely, you'll most likely want to set up a build server that can run your builds automatically. My team is using Jenkins for this, which is a little more work to set up, but it's free (aside from the ec2 box we run it on). There are also a ton of subscription based build/continuous integration servers, such as Travis and CodeShip. There's plenty of articles on the pros and cons of these different products and how to set them up. The bottom line is you'll want to have a build server that can pull down your code from source control, install npm deps, lint, test and build your app. If anything fails it should fail your build and if your build succeeds you'll have some sort of archive that you'll later deploy to an ec2 instance. In our shop we use a build.sh file to tarball up our build archive (basically a folder with our node server files as well as our minified client files, css files and any fonts or images needed to run the app) and upload it to an S3 bucket that we deploy from. We like this fairly old school method because the tarball will never change, so we have ultra reliable roll backs.
What you do with your build archive will depend on how you want to do deployments. We have a custom deployment system using puppet, but there are plenty of products that do this such as elastic beanstalk, that would be much easier to set up. You'll want some kind of process supervisor to actually run your node app, so unless you have a dev ops team that wants to build custom pipelines, using AWS built in features will probably be the easiest way to get started. As usual, there are so many ways to do this, but the basic principal is that you need something to download your build archive and run/supervise your node process. You also may want to be able to create and configure ec2 boxes on the fly (Puppet, chef, etc.), or even use containers (Docker) which allow you to move complete stacks around as single units. Using automation to create and configure servers is crucial if you need to scale your app, but it is complicated and may not be necessary for smaller projects. This is definitely an area where you can start simply and add complexity later on, as long as you have good long term goals and make sure to take the necessary step to prepare for future complexity.
All of this can get you pretty far in the weeds, so it's best to find the simplest thing that will serve your needs as you get started and then add complexity as real life situations demand so. I'll be happy to elaborate on any of these details if you provide a little more context about how big and well funded of a project your working on. If it's a little side project to learn the tech, I'd have very different advice then if you're trying to build an app that'll have a lot of traffic and/or complex features.

This could get 100 different answers and they could all end up being good ideas. First, you mention react + nodejs - keep in mind that these solve different tasks. React is going to be frontend and served out via static files. Nodejs is focused more around the server-side and would be the code that serves data. They can easily work together. You might use Express for the webserver (nodejs) to serve the HTML/React pages.
Unfortunately, I saw that you mentioned webpack, so you are going to have to 'build' your application with something - either via webpack, gulp, grunt, etc. This is where source control and build servers are great - but if you're new to it, it might be more complex than you need.
If you have just basic EC2 images as webservers and only 1-2, then the biggest hurdle is just pushing up your code. Something like https://deploybot.com/ could work as it can push your git repo down to multiple hosts via ftp, etc. If you wanted to get a bit fancier, you could look at something like Jenkins or some of the other items.
Docker is a great choice and if you are going to be dealing with multiple developers, server environments, deployments - it's worth the time. Otherwise, keep it simple and just get your code on the EC2 instance ;).

Breaking a React-Native application into plugable modules

I am looking to write a React-Native application. I want to be able to download new modules at run-time on the device to extend functionality. There would be some core logic that knows how to request new modules based on some form input like a dbs. I do not want to bundle everything into a single monolithic bundle which is what I believe happens now with the built in packager.
This would something similar to how RequireJS works in browser. What I need to know is:
How do I build independent modules? react-native bundle doesn't seem to allow me to select which root modules to begin with and only works on root project
How can I at run-time request new functionality be injected into the current JavaScript environment?

React native starts by pointing at a JS bundle. This means that you would at least have to restart the app to reload the js bundle (assuming that you're reading it from a server and not from the ios device itself).
If you did have a way to update the js files on the server (through some sort of web service that updated based on things the user does) then restarting the app could theoretically reload the JS and provide new functionality to the app.

I was able to get something pretty close to this in JS only. First I had to expose a few more options in the current react-native bundler, mainly, the url (to change the "main" module) and blacklist (to keep from bundling react-native in second bundle) options to their packager (http://github.com/facebook/react-native/blob/master/packager/README.md).
I then had to write a custom fetcher that would download the second bundle and use eval() to evaluate it in the current environment.
The one rub is that I had to add __d('react-native',[],require('react-native')) in the first bundle which I think work like define() from require.js. This exports 'react-native' as an unmangled name that the modules which I plug in can access via normal require() statements. It's a bit confusing at first but from what I can tell they React-native packager works a little like r.js (see http://requirejs.org/docs/optimization.html).

How to automate jshint as part of build process?

I want to automatically run JSHINT on all my javascript files as part of our continuous integration environment (actually, probably as part of TFS Gated Checkin, but I'm not sure yet as it will depend on speed).
I tried using rhino-jshint like this:
java -jar js.jar jshint-rhino.js myFile.js
but how can I set the required JSHint options? I know I could list them in a comment at the top of myfile.js, but I've got lots of javascript files, and I don't want the options duplicated in all my source files. (Or does JavaScript have an 'include' feature that I'm not aware of?)
I had hoped to pass an options.js file in as a parameter on the command line, and then keep options.js under version control. But I don't think this is possible with jshint-rhino.js.
Additionally, we are using a Visual studio extension to 'JSHint' all JavaScript files as we save them. But this tool cannot be ran on the command-line. We want the best of both worlds - running JSHint inside Visual Studio and Automated for the CI build, and then without duplicating the options (and indeed keeping the options under version control).
So the question is, how do other people automate JSHint in their development process?

If you want to check your Javascript while running a TFS build I would recommend having a look at sharplinter:
https://github.com/jamietre/SharpLinter
This contains a executable which allows you to check your Javascript files with JSLint/JSHint. To run this during your TFS build you could create a Code Activity which can be included into your workflow.
This video by Marcel de Vries from the Techdays 2012 goes through the automated build process step by step, and gives a demonstration on how to include your custom activity.
http://channel9.msdn.com/Events/TechDays/Techdays-2012-the-Netherlands/2361

Since you are essentially wanting to use a command-line activity inside of the TFS 2010 build process, then it is actually pretty simple. You'll want to add an InvokeProcess workflow activity (see MSDN documentation) at the point you want to run the tool.
There is actually a walkthrough available for how to do this with a different command-line utility but you'll just replace it with your own. The workflow activity even allows you to specify a set of command-line parameters that you can pass in.

Look at both http://gitcasette.com/ and http://net.tutsplus.com/tutorials/javascript-ajax/meeting-grunt-the-build-tool-for-javascript/