I'm kind of a noob to this kind of thing. I'm interested in using MIDI.js (https://github.com/mudcube/MIDI.js/) to build a musical web app, not too different from the demos they have listed and downloadable.
My expectation of MIDI.js, which is not well documented, is that it would be a bunch of javascript code that I can use, sort of like jquery.
So I don't have an understanding of the role of a "build" folder, or node.js, or a gruntfile (barely know what that is).
My question is, what is their to build? There are several example html files (with js) included in the download that run right away on my local apache server, so what is left to be built?
Thanks
From the repo it looks like the build step simply concatenates the various source files into a single MIDI.js file as well as creating the minified version.
Related
I’ve just got started with Swagger and NodeJS. I was able to implement Swagger to my NodeExpress application and was also able to generate typescript-client-code with Swagger-Codegen (Typescript-Angular) to be exact.
One problem that I have is the generated code is so spread out many different files. I was hoping that it only output one file api.ts and it contains everything from API calls and interfaces/models.
I’ve been looking for a way to solve this problem because it is hard to read and maintain the generated-client-code as the backend grows.
Any suggestions or pointers would be much appreciated.
Happy Holiday! Thank you
EDIT: I have been looking for answers for this for a couple of days and still haven't found one. I'm currently working on a project with ASP.NET Core and they have NSwag which does what I want to achieve with Node Swagger.
TL; DR
You may compile all files into a single *.ts file as shown at this post.
Continuous Integration Approach
Swagger code generator simplifies maintenance because it allows you to think in terms of continuous integrations.
You should not be worried about code review or aesthetics (because it is a machine generated code), but about:
API versioning
Functions, methods and classes signatures
Documentation
If you are working with a CI system such as Jenkins or Ansible, you could automatically deploy the library to a private NPM account (for JS and TS) or Maven server (for Java and Kotlin).
Keeping the package version number consistently updated will allow the IDE to correctly prompt the user about updates on the API.
Swagger uses Mustache templates for generating the code. For making simpler
changes you can simple create a copy of one of the built-in templates and
modify that.
Then you can use your modified template like this:
swagger-codegen-cli generate -t path/to/template/dir/ -i spec.json
The output directory structure, however, cannot be changed using templates
alone. For that you'd need a custom codegen module. You can either create your
own or modify one of the built-in ones.
Project I'm working on
I am starting a webaudio project in a team in which we are making audio effects, audio visualization and audio synthesis. We are now designing a basic folder structure. Each of us is thinking of a structure and in our next meeting we will choose the best one. One of the team-members is really experienced with Javascript, but I'm leaning more to Dart, cause it just feels more familiar and robust. I have a Java background, but I'm not really experienced with web development. Therefore I want to develop the software in both languages: Dart and Javascript, so that I can eventually get to a solid decision whether it is better to use Dart or Javascript for this project.
Directory structure?
I want to subdivide the dart libraries in three main directories: effects, visualization and synthesis. But I don't know yet where to place those main directories. According to the Pub Package Layout Convention the libraries should be located in the lib directory. But since all libraries will strongly depend on the webaudio API, it will only run in a browser, and thus be web application. So my first question is: "Should I place my libraries in the package/libs directory or somewhere in the package/web directory?" And "Should I put the javascript counterparts in the same directory?" For example: both oscillator.js and oscillator.js in the synthesis folder.
Switch between Javascript and Dart?
Once that the directory structure is done I would like to be able to easily switch from the Dart version to the Javascript version and vice-versa, and since I need a browser with an embedded Dart VM that will be Dartium. So here goes my second question: "What would be the best way to easily switch between the Javascript and the Dart version?"
Thanks in advance!
PS: I know that I could just use the generated Javascript from dart2js, but I want actually readable Javascript. And the dart2js Javascript does not exactly meet that requirement. Furthermore I want to have good understanding on the differences between the two languages, and I think that the best way is to try them both.
Edit: I would like to clarify the idea of switching between Javascript and Dart on Günter's demand. I will make a Javascript port of every Dart file manually, just so that I can learn both. Since I will be developing both of them at the same time, I want to be able to test the site with the Dart version, but also with the Javascript version. So I want the HTML to load this if in Dartium:
<script type="application/dart" src="main.dart"></script>
But this if in any other browser:
<script src="main.js"></script>
I reccon that dart.js in the browser package does this to switch between *.dart and *.dart.js, depending on if the browser has a Dart VM or not. But I want it to switch between *.dart and *.js (my own js), without having to make two separate html files.
Question 1: All in lib/ except entry points is fine.
Question 2: You can use pub serve. This allows to access to the app from Dartium or any browser from the same url. Any update in a dart file will be compiled when a *.dart.js file is request instead of a *.dart file.
For your edit: you can have a look at the dart_to_js_script_rewriter package to do a transformer that will rewrite your <script type="application/dart" src="main.dart"></script> to <script src="main.js"></script>. Switching from JS to Dart will be done by adding/removing your created transformer to pubspec.yaml and restarting pub serve or pub build.
We are developing multiple Java EE applications (8 for the moment) that are all based on the same sort of code. However, all the apps are clearly separated as different projects in Eclipse, they all have their own folder on Windows Explorer, and they all have their own repo on the Git server.
The idea was to put the redundant code somewhere (another project named "core"), and use it on every apps automatically without having to recode the same thing 8 times.
For the Java part, we did a "link source" in each project, which create sort of a symlink inside Eclipse to the "core" project, and use the specified "core" package in Java source with no problem.
But it doesn't work so well for the JavaScript/CSS part. I have absolutely no clue about how to code my redundant JS/CSS onto the "core" project, and use it elsewhere without having to manually copy it each and every time I modify it.
I think you should look into git for a solution to your problem. After all you still want the js file to be included in every project, but be maintained in a seperate project (as far as I understand it). There ought to be some sort of submodules and/or commit-handles or whatever to solve this using git.
This is what the User Library functionality in the JavaScript Include Path properties of your project is for.
I'm very keen to make use of some build techniques in my Javascript/Web App development such as
Concatentation
Minification
Image replacement with data:uri's
Build vs Source *
App Cache Manifest generation *
It's those last two that I haven't found an answer for yet.
Build vs Source
By this I mean having a "source" version of my HTML and Javascript that is untouched so that I do not have to build each time to preview a change. All of my JS files are separate <script> tags as usual with the build vs updating these script sections with the final concatenated versions. To be honest I feel like I'm missing something here with all of these new Javascript build systems as this seems like an obvious need but I can't find anyone else talking about it. How is everyone else dealing with this?.. Build on each change during development?? surely not.
App Cache Manifest generation
This explains itself - walk through my source tree and build up a manifest and insert it into my <html> tag.
I've searched for these two with no luck - any pointers?
I'd be on the road with a killer build system if it wasn't for those two.
Thanks!!!
Re: Build vs Source
It sounds like you're already familiar with grunt. You may want to consider looking into the grunt node-build-script plugin.
It adds a number of new tasks, notably grunt mkdirs and grunt copy which duplicates your project directory into a separate staging folder and then copies your optimised project into a publish folder. If I'm not mistaken, this is what you mean by keeping an 'untouched' version of your source files?
Running grunt server will then serve up the contents of your publish files on localhost. You could always point your web server to your initial project directory if you want to examine your application in its unoptimised state.
node-build-script adds a bunch of other super convenient tasks, such as image optimisation, automatic file revving and substitution. It's incredibly easy to use and super customisable.
I have a basic single page template which uses node-build-script which also may be of interest.
Re: App Cache Manifest generation
I believe this used to be part of node-build-script but was since removed, see 1, 2
There would be nothing stopping you from creating a custom grunt task that utilised something like confess.js however.
Finally, it looks like Google's upcoming Yeoman might be worth keeping an eye on if you're not already!
On a recent project I have been working on in C#/ASP.NET I have some fairly complicated JavaScript files and some nifty Style Sheets. As these script resources grow in size it is advisable to minify the resources and keep your web pages as light as possible, of course. I know many developers who hand-feed their JavaScript resources into compressors after debugging and then deploy their applications.
When it comes to source control and automated builds in the satisfying world of continuous integration (thank you CruiseControl.NET); hand compression will simply not do. The only way to maintain source control and offer compressed resources is to keep JS/CSS source & their minified brethren in a separate directory structure. Then register only one set of resources or the other in code-behind. However, if a developer makes a change to JS/CSS source and then fails to re-compact it and check in both versions, then you’re code-line is now out of sync. Not to mention inelegant.
I am thinking that it would be nice to write a custom executable (if one does not exist yet) for the CC.NET task block which would find and compress all JavaScript and CSS resources in the target directory after the build action but before the asp.net publish to target. This way, developers would only work on JS and CSS source and users would only get the minified resources.
Is there an application that already performs this task and if not, what kind of resource(s) should I look to install on the build server to have CC.NET execute?
(The closest question I could find here to this one required NAnt, which is not an option in my case.)
EDIT:
Dave Ward now has a great article on how to automatically minify in Visual Studio at his site.
The MSBuildCommunityTasks Project has a few MSBuild tasks that may do what you are looking for including Merge and JSCompress.
You could add these into your MSBuild project in the AfterBuild target to allow the project to perform this action every time the project is built and nothing would ever be out of sync. Your web application could then reference the compacted version for run but the developers would edit the full versions.
Nothing else would be needed on the server except the MSBuild community tasks assembly. You can put this assembly in your own source tree and reference from there and your CI build should get that assembly and everything it needs when it builds.
Another JS (and CSS!) compression library for MSBuild:
http://www.codeplex.com/YUICompressor
This is a .NET port of the java-based Yahoo! compressor.
Not a perfect answer, but if you're using MVC4 they've built this in as a new feature. When running a Debug configuration, it outputs individual files with comments and such but when you switch to Release, it will automatically bundle, minify, and change in page references to the minified files. You can setup separate bundles for, say, jquery and your own js. This works with CSS and JS files.
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
If MVC4 doesn't work for you, you can also find packages on Nuget that can help such as this:
https://www.nuget.org/packages?q=minify