I have quite a few co-workers and friends with existing brownfield, messy javascript applications who would like to start transitioning to some sort of js module system. I've tried to help them out in the past by showing them how to refactor to requirejs but I'm starting to think that is a bad approach.
The problem is usually that the nature of their globals-all-over-the-place code conflicts with the asynchronous nature of AMD, and as much as I believe in the AMD approach, they have bigger concerns than my lectures on the "proper" way to do module loading.
Browserify in the meantime removes the async consideration and is more straightforward but adds in a whole build step. For people who are not using bundling or any sort of a build process (or just the default one in visual studio) this is again, too much overhead.
So what I really want is a simple module system that allows people to define and require things. This is a half-step toward getting things working properly, they can include their dependencies with regular script tags and define them into the module system manually. I even wrote such a system because...hey, that's really easy.
Today someone pointed out to me that it should be possible to actually use just the client-side pieces of Browserify to achieve this. I agree. However, I can't really find any documentation anywhere nor just the Browserify client-side stuff in isolation.
After sitting down and dissecting a built browserify file I've concluded that no, what I want to do is not possible.
For one thing browserify doesn't seem to expose a define or even a require keyword. For another, it does some minor rewriting of the combined modules which would be very difficult to achieve during runtime.
I ran across a dynamic module loader that works well with Browserify. You can use it for development to expose "require" globally on the client side. Works great.
https://github.com/manvalls/drq
A solution to your problem could be:
https://github.com/LarsBV/browser-node-loader
I wrote this due to various sourcemap bugs in browsers, and too many / alternative,
configuration ways in gulp/browserify/watchify.
It has a build step but it only needs to be run when there is new dependencies.
I don't recommend this approach for production, but it is so much easier in development.
This is very new, and untested in anything but latest chrome, firefox, with some adjustments
in the generated script I think it will work in even ie6.
Related
I am adding a typescript project to a VS2015 MVC 5 project (that makes it ASP.NET 4, not asp.net 5 or asp.net 6 code: only the MVC is version 5). This is the sole target for all aspects of my question, I cannot use generalized or theoretical guidance on typescript, node.js, module loaders, etc.
The problem is simpler with ASP.NET Core. But that's not what I'm facing. All the usual sources of examples and guidance avoid or provide scraps when it comes to ASP.NET 4 MVC 5 because it is hard. And no one will state exactly how hard or what precisely are the obstacles.
Worst, Typescript documentation is like Open Source Documentation: you can only get one issue, one step deep. This produces a research workflow consisting of endless-issue-tree-recursion.
I understand opinions, I even have one. But I'm looking for the experiential answer, what is the one combination that has proven to work for a production team.
So here are the specific items that need to be addressed and made to work within the confines of a working, medium-sized ASP.NET 4 MVC 5 LOB app:
Visual Studio's version of typescript. This is an installation issue (using node most simply) and the Tools/options - typescript settings have to match.
Browser-style testing (typically manual TDD workflow) or node.js testing (automated). This has to be chosen up-frontly to prevent more issue-tree-recursion. We are going with browser-based... phantomjs using WallabyJs.
NPM #types/library-name: supposed to fill a node_modules folder with both library-name and library-name.d.ts based only on a package.json with #Types references. But actually requires the package.json to hold a reference for both the #types/library-name and the library-name to work in my VS 2015 ENT v3 and asp.net 4 mvc 5 project. And all the versions specified then require manual correction' and even then the version look-up process is a little suspicious. This #types process may not be the way to go with ASP.NET 4 MVC 5, but I can't tell what the correction alternative might be. #Types is currently the only recommended option for typescript.
Which version of ECMAScript: es6 is apparently too far ahead. es2015 is likely, but this (maybe) appears to have relationships to several of the other issues. Supposedly, these designations are the same, but there are two places they can be set. I've chosen es2015 in tools/options/typescript. But getting any of these (now 3) settings wrong could be a problem.
Module system: CommonJs is for node and automated testing, and VS development testing is automated only for server-side, and VS UI tests are a manual process. So AMD, require JS is probably an option for VS, but it adds its own workflow and maintenance and considerations that are really hard to get right in ASP.NET. Using ASP.NET bundling and triple-slash references (dependable) might work, but after you have put the libraries in node-modules, you would want to use the full path into node-modules in the file name slug in an import statement. This is all very clumsy and involves the most guesswork. But solving this whole item might be the 'key' for the overall question.
There are probably a lot of other, smaller issues. But someone who has done this will have solved all the mentioned items and the others as well.
What I'm looking for is all the settings across all these issues in detail based on a working Typescript app in ASP.NET 4 MVC 5 implementation for browser-based unit/behavior tests in VS 2015. Those who have done it will understand.
Thanks very much for your consideration.
What you're missing is separation of concerns, in spite of the initial benefit of such starter templates, they start to cause incidental dependencies and complicate the mental model. It's much easier to have your front end in a separate project.
Regardless:
Visual Studio's version of typescript.
Always use the very latest available. This controls the version of TypeScript which powers the IDE. You will probably end up compiling in a separate process or in the browser during development. Again you will want to use the latest but it will likely be installed with a different package manager.
Browser-style testing (typically manual TDD workflow) or node.js
testing (automated). This has to be chosen up-frontly to prevent more
issue-tree-recursion.
Firstly, I definitely agree with the importance of choosing up front but, if it is still possible, just unpleasant, to add tests to an existing project.
TDD workflows involve automated testing as they rely on rapid feedback. This is orthogonal to whether you run your tests in the browser or using NodeJS.
You should use whichever approach makes the most sense for your application and that may be a mix of both.
Since you are writing a frontend JavaScript application you will likely want to run some tests in the browser. However, as Uncle Bob (Robert C. Martin) has stated, views should be dumb and require little testing. My interpretation of this is that we should not spend too much time testing things like Angular or React components to ensure that they render correctly, and instead focus on testing behavioral elements of the system such as services and plain old functions.
That said, you may well want to run tests of your client side services against an actual browser runtime, as opposed to just Node.js, and that is reasonable.
There are a number of testing libraries to help you with this. I do not have a specific recommendation besides to say that you should find a reliable test runner, and a simple assertion library. Tried and true testing libraries like QUnit and Tape are examples of solid options.
One last note, it is important that one not confuse the concept of integration testing with running tests in a web browser, it's perfectly valid to run TDD style tests, which implies unit tests, in a web browser.
NPM #types/library-name: supposed to fill a node_modules folder with
both library-name and library-name.d.ts, but requires the package.json
to hold a reference for both the #types/library-name and the
library-name to work in my VS 2015 ENT v3 and asp.net 4 mvc 5 project.
Simply put this goes to back to decoupling your front end from your back end. Visual Studio and certainly ASP.NET have nothing to do with versioning your types packages.
If a package comes with its own type declarations then you don't need to install an auxiliary types package otherwise you do.
Either way install JavaScript and TypeScript dependencies using a JavaScript oriented package manager (such as NPM, JSPM, or Yarn).
Do not use NuGet for these!
As you suggest there are versioning issues, it's currently a difficult problem in TypeScript. However once again it has nothing to do with ASP.NET or Visual Studio.
Which version of ECMAScript: es6 is apparently too far ahead. es2015
is likely, but this appears to have (maybe) relationships to several
of the other issues.
ES6 is the same as ES2015, the latter being the name under which the former was ultimately released. ECMAScript now follows a yearly cadence, roughly, with ES2017 just around the corner.
The nice thing about having a transpiler, such as TypeScript, is that you can use the latest features from es2017 and still target es5 for emit and you'll be fine.
Module system: CommonJS is for NodeJS and automated testing, and VS
development testing is automated only for server-side, and VS UI tests
are a manual process. So AMD/UMD require JS is probably the option for
VS, but it adds its own workflow and maintenance and considerations.
Using triple-slash references (dependable) might work, but after you
have put your/their libraries in node-modules you would want to use
the full path into node-modules in the file name slug in an import
statement. (solving this whole item might be the 'key' for the overall
question).
This is a very complex subject and probably the only one of your questions that you really need to spend a lot of time considering. As I said earlier using NodeJS or not is orthogonal to automated testing. But if you're targeting NodeJS natively with your test code then you will need to use CommonJS output.
For the actual application code, the choice has nothing at all remotely to do with whether or not you are using Visual Studio, I'm sorry for reiterating this but it really is important that you separate these ideas.
The question of which module format to use for your front end application code is a very important and contentious one.
Triple /// references are not a module format but rather a way of declaring the dependencies between global variables that are declared and referenced across multiple files.
They do not scale well, working acceptably when you have only a handful of files.
Triple /// references should not be used. They are not a modularity mechanism and their use is completely different from using any of the module systems/module formats you mention, including CommonJS.
Never combine them with a module system, which is what you would have to do in order to run your tests under NodeJS or load your app with RequireJS or anything else.
RequireJS is an excellent option which would imply AMD modules as you say. RequireJS does not require any use of triple slash references. In fact they should be avoided as the plague when using this format or any other module format!
I recommend strongly against using UMD modules. Isomorphic JavaScript is a problematic idea, and it offers you no benefits since you are creating a browser application with a .NET backend.
Many developers actually do use CommonJS modules in a browser. This requires bundling them continuously, using tools such as Webpack. This approach has advantages and disadvantages. The primary advantages are the ability to lean on existing NodeJS JavaScript server-side tools, such as npm, by way of Webpack or Browserify. This may not sound like a big advantage but the amount of rich tooling available for CommonJS modules is nothing to scoff at, making it a strong option.
Consider using the System module format and the SystemJS loader via jspm to both manage your packages and to load your code. With this approach, you gain the advantages of RequireJS, are able to run your tests under NodeJS and the browser using jspm run without needing to switch targets formats or bundle your code just to test it. There's also no need to bundle your code during development, although this is supported. More importantly, you gain the advantage of writing future compatible code, as it offers the only module format and loader which correctly models the semantics that ES Modules will eventually have when implemented natively in browsers. JSPM has first class support for TypeScript, Babel, and Traceur.
For posterity here is the description of the System module format taken from the link above:
System.register can be considered as a new module format designed to support the exact semantics of ES6 modules within ES5. It is a format that was developed out of collaboration and is supported as a module output in Traceur (as instantiate), Babel and TypeScript (as system). All dynamic binding and circular reference behaviors supported by ES6 modules are supported by this format. In this way it acts as a safe and comprehensive target format for the polyfill path into ES6 modules.
Disclaimer:
I am a member of the JSPM GitHub organization, playing a role in maintaining the registry and have made very minor contributions to the jspm cli.
I've purchased CodeKit a while ago, it makes front end projects really easy to setup.
The problem is, I'm in what I call a 'Front-end tool hell'
I've checked out Grunt and Yeoman a while back, and I don't see the point of using these tools if I'm using CodeKit. Am I missing a point?
Short answer: No. You don't miss anything
Longer answer: All of those tools (maybe with the exception of Yeoman) tackle the same thing, but from completely different directions.
Codekit is great to start, because it's like a Swiss army knife of tools, where you actually don't have to do that much work to get it going. Easy to configure and totally easy to use, especially if you don't have any command line experience.
If you want to have things more flexible and you need maybe more than the provided tasks (running a server, creating proxy connections, FTP uploads, having tools included which CodeKit misses); or if you simply need to integrate your builds in continuous integration environments, you will most likely end up with a command line build tool, and also most likely with Grunt. Grunt's biggest strength is in having multiple configurations for different environments. So if you want to have the same code compiled in different ways for different destinations, that works wonderfully with Grunt.
If Grunt can't offer you more than CodeKit, fine, stick with CodeKit!
Grunt has also its limitations, especially in terms of execution time and intermediate file results. That's because in Grunt you take a defined process and configure it. Gulp on the other hand allows you to define the process itself, thus making it even more flexible.
Oh, and concerning Yeoman: If you have a basic setup and like it, write a Yeoman generator and easily scaffold new ones by the push of a button. Or, if you are new to things like, let's say Angular, take a community generator and see what the pros think it's best for such an application. I'm not sure if CodeKit can do "project templates" by now, but that's the idea behind it.
Hope this helped.
What are the pros and cons of ussing Assetic vs Grunt in my project? Which one is "better"? I heard that dealing with Assetic is a lot of pain, for me it looks ok, but I never used it that much. I found this http://konradpodgorski.com/blog/2014/06/23/better-way-to-work-with-assets-in-symfony-2/ and Grunt looks pretty good. I could try both myself but I'm in the middle of fixing a project and I need to choose some technology ASAP, so I need tldr; version of advantages and disadvantages of using either technology.
never used grunt together with symfony2, but i promised to myself that i will do it the next time.
building and watching for changes including possibly livereload are definitly the pro's for grunt! another pro for grunt is that there are thousands of plugins available, which could potentially do stuff like image-minification, uncss and so on. i don't think there is an easy way to do this with assetic.
overall it possibly depends on your usecase. if you simply just want to concatenate files it is probably easier to use assetic. otherwise i would definitly choose grunt (i'm confident in using grunt, just because i used it a lot)
Assetic is PHP so you can manipulate it at run time. Bundles can extend your templates and add stylessheets etc automatically.
On the other hand grunt is JavaScript and cant be integrated into your program at run-time but it supports a wider array of tools and is easier to configure.
I've been recently reading up on SASS(Simply Awesome StyleSheets) on codeschool but when I actually tried installing it, it turns out I need to install RVM(Ruby) as SASS was written in Ruby.
So I have a two questions here:
I understand that there are other CSS frameworks like LESS but they don't seem to be as powerful/popular. How true is this? I wouldn't mind switching to LESS if does not need Ruby at all.
Is there a compiler for SASS in .NET or Java family of languages and if there is, how production ready is it? I do not want to keep checking the generated CSS file when debugging or making changes.
1.I understand that there are other CSS frameworks like LESS but they don't seem to be as powerful/popular. How true is this? I wouldn't
mind switching to LESS if does not need Ruby
Here is my take on this.
LESS like SASS is a CSS preprocessor but it is pure JS based and thus can be parsed directly by browser if you include less.js file in head. You may also generate a CSS file offline and then ship it to production. Please note that you will need node.js to actually run LESS. LESS is built on top of it. LESS if not more powerful than SASS, is equally powerful in terms of features. Go ahead and use LESS, you'll never miss a thing about SASS.
2.Is there a compiler for SASS in .NET or Java family of languages and if there is, how production ready is it? I do not want to keep
checking the generated CSS file when debugging or making changes.
There is actually a C version of SASS called libsass. See its site at http://libsass.org/.Libsass is just a library. To run the code locally (i.e. to compile your stylesheets),you may use SassC https://github.com/hcatlin/sassc , an implementer written in C.
This really comes down to what you want to your preprocessor to do and which fits your project requirements the best. People will argue either or all day long. For me what I see the main difference is that in LESS I can't do as many programatical things, like loops, for each statements. That kind of thing.
SASS is ruby based, therefore you need to have ruby installed. There are extensions you can use in Visual Studio to make SASS compiling easier. Web workbench and Sassy Studio. Support will be coming to Web Essentials some time soon.
So I think it comes down to which you think fits best. I prefer to use LESS in Visual Studio (using DotLess) just because I feel it's better supported and I don't need to install Ruby (I big consideration when working with multiple developers).
95% of my time I program ASP.NET (MVC) web sites.
Should I care about MSBuild?
We use MSBuild with CruiseControl.Net to manage the builds of most of our big ASP.NET projects. For every commit of one member of the team, a build is launched. It helps us detect
quickely incompatibilities before moving a feature to "staging" or "production".
I think it is really usefull when working with a team on the same ASP.NET project or if you are working alone on a big project.
That depends on your development environment.
If you have other folks that do deployment of your systems, and they take care of the build and deployment environment, then MSBuild probably won't be necessary for your work.
On the other hand, if you need to configure the build script to understand special situations that your code comes up with, then you will definitely need to understand MSBuild scripts.
Even for a one-man shop, it's a useful tool to know, especially if you are configuring a continuous integration server like Hudson.
No. Until you have to.
Its not absolutely necessary to know MS Build, but it is useful to know.
It might not be needed for all kind of projects, but it is extremely useful when you are working on a huge code base with automated custom build solution/ nightly build/developer builds so on and so forth.
It's unlikely, unless you choose to use it, or you start to make use of Team Foundation Server's Team Build.
Your development processes need to get to a certain complexity before automated builds really deliver their true value and/or if you find need for automatic deployment (including database changes if applicable).
The coming Visual Studio 2010 is going to make it far easier to use, but for now it retains a fairly steep learning curve which you can avoid by using alternatives, or commercial products (e.g. Visual Build Pro, Final Builder etc).
The nice thing is that it is part of the .Net framework, so it's already available as long as you have the framework installed (which it probably is).
So, in short, not really. It's something very useful and powerful though, setting up deployments using MSBuild can be very, very useful.
What should a developer know about MsBuild?
Every developer should know it exists and it's basic capabilities. If know it exists you won't duplicate its features and will know what it can do for you, when you need it.
Minimum:
As an exercise, build your project through the command line: msbuild myproj.sln
Know the role of continuous integration
A little more than minimum:
Hack your csproj (or vbproj) with a message task, so it outputs something during clean.
All done. When you need to know more, you'll figure it out.