I am new to nodejs and grunt.
I was going through the less-middleware and was very impressed with the way it automatically creates the css files. I now want the same for js files also. Let me briefly explain -
User makes a request to site.min.js
The routes automatically captures the particular request.
Nodejs creates a new combined and minified js file based on the input parameters if the file is not already present.
Return the combined file.
I feel grunt is not the right way to go about it since every time the js files are updated I will have to commit new version of the min file to the repo. I want some dynamic mechanism of creating the minified version.
Also not that i am trying to deploy my code on heroku.
Grunt will compile your js files during the build. I'm not aware of a runtime pull-and-minify for javascript.
Related
I have the following code in my app.js file,
app.use(express.static('views/app1/dist'));
app.use(express.static('views/app2/dist'));
but here I have same named JS files in both folder, they are designed to represent respective HTML file present in the same folder.
The problem here is that even though I am routing to "app2" HTML file, the "app1" JS files are getting called.
Need help in making NODE understand which folder files to execute.
The code screams that you are using NODE.JS with EXPRESS, and Angular 4, so following are the tips for you:
Avoid having files with the same name, it increases the computation load on the server,
Instead of using ng build, use ng build --prod, this will create unique named files, so no clashing.
Some questions to put angular2 web project to production environment
We do development on lite server but what is best for production? Is is some other server module of nodejs? Technically we can have any server (apache, tomcat, etc).
How should we do source code management for below context.
browser must include js files so project should have js files when deployed
In standard java project we just commit .java files and uses jenkins (may be other tools) to compile and make the deploy-able structure
Should we follow same strategy here? i.e. don't commit compiled js files and deploy using some node compiler which takes ts files and compiles it to js
What is the best way to minify/obfuscate the js files
I know a way using outDir and outFile with grump but I don't want every files tobe included in one minified file because it kills the concept of lazy loading
Is there a way to minify and obfuscate js files on compile time only?
What enableProdMode() do? How it is different than not using it?
Here are some answers to your questions:
Angular2 applications only consist of static files so they can be serve by any static Web servers or server applications that can define static folders (Express, ...)
Regarding source code management, you must have a packaging phase to optimize the application loading (gater files, uglify, ...). Your source code must contain your TypeScript files (or JS files if using ES5 or ES6). Such packaging can be done using Gulp for example. Your Jenkins server will be able to checkout the source code, build it and execute tests.
In fact, when not using the outFile property of the TypeScript compiler, you won't be able to gather all the JS compiled files into a single one since anonymous modules will be created within each JS files.
See this question for more details of this:
How do I actually deploy an Angular 2 + Typescript + systemjs app?
Regarding prod mode, here is an extract of the documentation:
Disable Angular's development mode, which turns off assertions and other checks within the framework.
One important assertion this disables verifies that a change detection pass does not result in additional changes to any bindings (also known as unidirectional data flow).
I have written a small helper module in regular NodeJS to be used with NodeJS batch scripts. I've placed this and all the batch scripts in the "private" folder inside my Meteor project.
I'd like to also use the helper module on the server-side of Meteor as well, but I don't know the best way to handle that.
This is my current project structure:
client
... client files ...
private
scripts
helpers.js
batch_script1.js
server
... server files ...
So for Meteor to include the "helpers.js" file into the server, it either has to be located in the "server" folder, or imported via a package. Creating a symlink won't work, as multiple developers will be working on this and may have the repository checked out to a different directory location (seeing as how you need an absolute path to create a symlink).
I also don't want to have to duplicate the file and maintain two copies, so what are my options for sharing a helper script between a Meteor app and a NodeJS script?
Thanks
I was able to find help on the Meteor forums: https://forums.meteor.com/t/use-nodejs-helper-script-in-meteor/11056/3
We are using node js to minify javascript files in one single file. I want to know if there is a way to specify the order of the js files to be minified. Why? because we are using jquery-ui and moment datepicker. These two libraries are using a function that has the same name (datepicker). We are able to manage on the development environment to load first jquery-ui and after moment datepicker because we need the one on the moment datepicker file, so loading the files on this way, everything is good but when we end up on the deploying using Node JS, the jquery-ui comes at the end and overrides the moment datepicker and the datepicker is not working as expected. We are also using require js in our project. Any idea would be much appreciated.
Firstly I must confess I am a noob at node. I've been using ASP.NET then PHP then Django before. Regardless, I've found node a breath of fresh air. This problem is also not strictly a node problem, but I need a node specific answer.
I have an express server and angular frontend. The server side templates are in swig and currently only serve for error pages and the index page. Mostly the angular templates will make up most of the front matter.
What I'm struggling with, if only only in deciding how to do it, is getting an efficient work flow for the asset pipeline. Server side templates must be able to inject the vanilla of assets during dev and testing. The same for client side templates during testing. Basically, running with express' static middleware should be an option without any configuration (maybe with some helper in server side assets). Thus git clone -> grunt -> viola.
However, during staging and production, I would like the server side files to stay vanilla. The template helpers may parse a manifest file indicating the cache busted links (CDN path maybe too). How to make the link from logical asset bundle name to production ready asset is a mystery for me, while keeping development transparent.
The client side templates may be minified, concatenated, injected or whatever, as it will be saved to some dist folder for uploading. It is important that the whole dependency tree (images, fonts, css, js) must be "exported" to the dist folder.
To deploy would then be: pushing the server side code to the server and running. And pushing client dist folder to some asset host (CDN, nginx, another node, maybe even connect static)
What my question(s) then actually is(are):
Is this workflow possible with tools such as broccoli/gulp/grunt alone?
I've tried connect-assets but I don't want to conform to some predetermined folder path. Also the cli tool didn't produce the other static assets. Perhaps I don't understand the tool.
Am I following the correct approach?
I've added to a discussion on broccoli concerning the manifest file consumption:
https://github.com/mjackson/broccoli-rev/issues/1#issuecomment-49076249
Edit: I forgot to mention that I use bower, so assets should be pulled from arbitrary (URLs too maybe) locations.
I think angular-fullstack is what you want. Even if you don't use it, it does almost all of what you're looking for.
The only thing that it might be missing for you is deployment. It has built in support for Heroku and OpenShift deployment. You could use something like grunt-ssh or grunt-deploy for other deployment scenarios.