I'm looking to implement a build system that will run unit tests and JSLint on the Javascript, generate documentation and compress JavaScript and CSS into minified packages.
I might also add an integration step, which automatically uploads the code to a server on each build.
I feel overwhelmed by all the choices in build systems - some targeted toward .NET, others to Java.
What's the best system for my requirement, considering that the choice back-end is irrelevant?
Any build system would work, but there are none specifically designed for it. I would recommend either Ant or NAnt depending on if you're more comfortable with using Java or .NET. Either would work well for your purposes, running command line tools for the actions you want as part of your build.
You can also find 3rd party tasks specific to your tasks to make it easier:
Ant JSLint
http://jslint4java.googlecode.com/svn/docs/1.3.1/ant.html
For continuous integration I would recommend TeamCity. It will work well with any build system, provides a great interface, and is free for up to 20 projects.
http://www.jetbrains.com/teamcity/
Related
I am working on an audio editing prototype. At the moment it is very simple, so it currently works as a Web App using JavaScript, HTML and CSS. This makes it possible to build as an Electron app, using Node.js to access the file system.
However, it makes heavy use of a Python program called Gentle, particularly the file align.py. I was wondering if it was possible to integrate this program somehow, given how frequently it is used.
I am not familiar with Python, but I have tried to work out if this can be done. I have read about child_process, python-shell and zerorpc. However, if possible, I do not want to force the user to install Python along with all the dependencies required for Gentle, as it is a difficult process with lots of room for error.
This is where I have become stuck. Ultimately I am looking for a way to use Gentle in a way which gives the appearance of it being part of the functionality as a single self-contained program, rather than butchered on with duct tape.
I realize Gentle includes the option for a REST API and a Python server, but I am more interested in using Gentle offline for faster functionality. I am also too broke to afford hosting.
I realize I am kind of working backwards, as the front-end normally comes after the back-end. If it is easier I can try to rewrite the code base in Python or a lower-level language, but I am trying to avoid this if possible.
Any help or suggestions would be greatly appreciated!
You can compile the Python program and include the resulting binary file into your Electron app and just run the binary via child_process. There are several ways to create executables from Python programs.
About a month ago, I broke my computer out of stupidity. Today, I was given a computer from my aunt-the downside, it's pretty old and doesn't take WiFi as an internet input (only ethernet). So, I decided I'd just take what I was given, and use good ol Notepad and Edge to create a webpage using Angular. Now, I am by no means an expert in this stuff, I just wanted to experiment with what I could. That is, until I can get the Ethernet set up.
Because of my incapability to use WiFi, I can't install the library/framework through Npm in the Cmd (and I presume I can't script src a link for the same reason). However, I see that Angular is "100% JavaScript" so I thought that there might be a way to do so.
TL;DR ~ Can I still write in AngularJS without WiFi?
You will need be able to download the AngularJS or Angular libraries before you can start developing Angular applications. Until you can get internet access so that you can use NPM, you will have to ask someone to download the necessary files so you can develop with Angular. If you are new to Angular or unless there is a valid reason to start learning AngularJS(angular versions before version 2) then I would start with Angular. You will learn newer technologies such as Typescript, ES6, RXJS, etc. If you are new to web development and/or build systems I would take a look at Angular CLI. It will allow you to create Angular apps quickly without creating all the boiler plate code from scratch.
Yes.
You should be able to start up a localhost with something like NodeJS, MAMP, or some other server language.
If you can not create an http connection with a localhost, it shouldn't work as most modern browser sandboxing will prevent your JS scripts from being able to load.
I have been recently looking at installing either team city or Jenkins as a CI solution. I am quite aware of the advantages it can bring to my teams c++ projects with nightly builds to test if anything checked into git has broken the project or dependent projects. Also as a way of building and releasing software.
However I know people use it on JavaScript projects. These cannot be built as such and can only really be tested at runtime. So what is the real advantage of using a CI solution on a JavaScript project comprising of back end and web front end code.
Thanks for any advice.
While the build and test stages are typically looked at as 2 completely different CI steps they're fundamentally just verifications (OK, with a dependency in between them) which would have to ALL pass for the CI iteration to be considered successful.
When talking about breakages people typically refer to build failures, but fundamentally there is no difference from the usability prospective between an artifact missing because it failed to build and an artifact successfully built but DOA/unusable from the testing prospective - none of them can be shipped, they're equally blocking the larger team's development/testing activities, etc.
So if there is nothing to build for your particular context just skip that step (or make it an always BUILD SUCCESS bypass if the CI system doesn't support a missing build step).
You'd still get all the advantages of using the CI methodology/verification in your development process.
The purpose of CI is to detect problems early instead of waiting to find them at runtime. JavaScript should not be exempt from this process especially if you have a lot of it. Running static analysis, e.g., jslint/jshint and unit tests can and will save you a lot of headache in the long run. My team specifically uses Jasmine as our testing framework and we have a well defined set of JSLint rules. If any test fails or any rule is broken the code cannot be checked-in. In addition, we require code reviews for all our code (including JS). This, I belive, is the most valuable step in our CI process.
I've been catching up with the modern client-side JS ecosystem and reading up on module systems such as CommonJS and AMD (incl. associated tools - browserify, requirejs, onejs, jam, dozens of others). If I'm writing a Javascript library, how do I package it such that it can be most broadly accessible (ideally by users who swear by CommonJS, AMD, and especially neither)?
Popular libraries like jQuery seem to just use old-school file concatenation for building itself and dynamically detect whether it should write to an exports or the global context. I'm currently doing the same thing, but the main downside is that if I (unlike jQuery) depend on a few libraries, it's nice to not have to ask users to manually pre-include the transitive set. (Though I currently just have two dependencies.) And of course global namespace pollution.
Or perhaps it's cleanest to generate multiple versions of my library, for each context?
This also affects packaging and publishing. There are several systems, but I believe the major one is bower, which is easy to deal with since all it does is fetch. However, if I want to package it up for component, then that requires a CommonJS module.
Are there other relevant aspects I should be aware of? Are there any good example projects to follow for all of this?
I have been thinking about this myself and I came to several conclusions:
Create one version of the framework that can be used in both global and AMD setting
Don't obsess over having to ask your clients to include dependencies manually, it is a one-per-project activity and should be done anyway, whether you provide an AMD-packaged or global-scoped framework (3rd party dependecies placement will have to be adjusted anyway, is what I am saying)
I use Grunt for project building/packaging/testing/linting/whatever, so for all other packaging alternatives I have different tasks.
So, in short, build for "old-school/AMD" first, package for "new-age" later.
P.S.
I am also a firm believer that your packaging and delivering process/need shouldn't (whenever possible) dictate your architectural and development decisions.
I try to build the most customizable, modular and usable code I can, while using the packaging paradigm of my choice, then I consider alternative packaging. If I succeeded in the first part, second one is normally either straight-forward or requires very little codebase changes (because of the modularity and proper principles application in the first step).
I'm trying to grasp a bit of an idea here. And hoping someone can help clarify the best practice.
How do teams or pairs approach using a build system for javascript like grunt.js ?
I really want to break our large javascript files into smaller pieces and converting to AMD/Require isn't an option right now.
It seems the easiest way is to concatenate and minify to a master file. And we are using version control (SVN).
So I'm wondering what the best practice is here?
Are we asking for constant conflicts with the production file? How do other teams approach this?
Hope i made my question clear enough.
thanks in advance...
We recently faced a similar dilemma at my organization. Using AMD or RequireJS wasn't an option due the the sheer amount of legacy JavaScript code we have.
We ultimately went with grunt and came up with a "build" task that concatenates and minifies. Then, there's a completely separate "deploy" task that gzip's the files and uploads to Amazon S3.
We don't check in our concatenated/minified code to source control. In general, it's a good operational practice to have separate build and deploy tasks for your source code. For larger development teams, the deploy/build process would traditionally be done in a CI tool that runs whenever someone commits to SVN/git.
In your case, a simpler arrangement would be if you just manually deployed code from your development machine instead of have it automated from a CI tool. The problem with this setup is it's easy to run into conflicts with other team members.
That said, there is a growing number of open-source (Jenkins) or cloud-hosted (CircleCI) tools that might be worthwhile for you to look into.
Do not commit the output. Use a ci tool like teamcity to build and deploy. Only commit source files to source control.