I'm reading the book Angular 5 Projects and have come across this sentence:
The Angular CLI uses Webpack to transpile, compile, and deploy project code.
Transpile and compilation are given in the following link
The transpile is from TypeScript to JavaScript.
What language does angular-cli compile the JavaScript code to? And is angular-cli doing both: transpile and compilation?
Thanks for the help!
Typescript must be transpiled into JavaScript using the tsc compiler, which requires some configuration.
Yes, it's doing both. When working in Angular you will using TypeScript to code in files designated as your-component.ts with the 'ts' signifying that it's a TypeScript file. Angular then takes these files and does the transpiling (conversion to another language). In this case that would be TypeScript to Javascript. Once this is done Angular uses these now created JavaScript files to communicate to the browser with.
Related
I am trying to set up sass with Angular Dart but I'm a bit lost and couldn't find a documentation past 2016 (a good one)
I currently have the following structure:
However I cannot reference a main.css file as it is not found and if in a component I put something like this
styleUrls: ['lib/assets/sass/main.scss']
The webdev serve command fails
My pubscpec is
dependencies:
angular: ^5.0.0
angular_components: ^0.9.0
bootstrap_sass: any
dev_dependencies:
angular_test: ^2.0.0
sass_builder: ^2.1.1
build_runner: ^0.10.0
build_test: ^0.10.2
build_web_compilers: ^0.4.0
mockito: ^3.0.0
test: ^1.3.2
I cannot figure out what's wrong and also the structure I should use
Should I put in my top component main.scss (or the compiler main.css) and do not set any other file reference or should I include it at every component? And also how can I generate this compiled file when I run webdev serve
Thanks,
Alexi
So the references for styleUrls should always be the compiled css not the Sass file. Also the Urls need to be either relative to the file, or package format. So either 'main.css' or 'package:your_project/assets/sass/main.css'
I would also suggest not having separate asset directories. I tend to find having the sass file next to the component to be easier to maintain.
AngularDart also has style encapsulation by default; meaning CSS won't leak outside of the Components by default. Given this I find it better to have the CSS local to that component and be next to that component. You'll find that is the pattern on the angular components, and gallery.
One small note on the components, and gallery. They use the pattern style.scss.css instead of style.css which breaks the convention of Sass. The reasoning behind it is so that we can quickly tell what the source of the CSS file was. Was it written by hand, or did it come from Sass. This is achieved by having different settings in the build.yaml file. I don't think you should do this for your project tho.
With Laravel 5.5 I'm using laravel-mix to compile my assets.
However something is not clear to me: what is the difference between mix.js and mix.scripts and why would I use one instead of the other?
Mix.scripts will
...combine and minify any number of JavaScript files... This option is particularly useful for legacy projects where you don't require Webpack compilation for your JavaScript.
While mix.js will compile ES2015, bundle modules if any and also compile vue components.
My asset compilation in Phoenix is taking around 20 to 60 seconds each time, and it seems to be related to adding Elm to the project. What would cause this to happen?
I figured out this was happening because I wasn't telling brunch not to use the ES6 compiler on Elm code. It was compiling Elm code to a 10,000+ line javascript file and then trying to compile that through Babel. This is fixable by either putting the Elm code in the vendor folder (which is ignored by Babel by the default Brunch settings) or telling Babel specifically to ignore the (in my case) main.js file that is the output of the Elm code compilation.
I am new to browser development, so I have no prior experience with AMD, CommonJS, UMD, Browserify, RequireJS, etc. I have been reading a lot about them and I believe I generally understand the JavaScript story but I am still very confused as to how to make everything work together.
I have a library written in TypeScript. It is a pure TypeScript library, it doesn't interact with a browser or any browser framework nor any node or NPM things.
I also have a TypeScript client application that leverages this library. The client application may leverages a web framework as well (e.g., jQuery).
Now when I compile my two TypeScript files (which we will assume are in separate projects, isolated from each other and built separately), each will generate a .js file. In Visual Studio I have to choose AMD or Common as my module loader.
This is where things fall apart. My research tells me that if I want to work on the web I either need to use Browserify or RequireJS. Browserify appears to require I first install Node on my machine and then use a command line tool as a post-build step to generate a file and as far as I can tell this isn't available as a NuGet package. Alternatively, I can use RequireJS but then all of the examples stop working. Something about not doing things on window load and instead doing them somewhere else, but nothing that I have found really explains that well.
So, what is the story here? I want to use TypeScript but at the moment it really feels like it is just a language, there aren't any compelling usage stories available to me as a developer as I have grown accustomed to in the Microsoft ecosystem.
TypeScript does support AMD and CommonJS just as JavaScript. But in addition it also supports internal modules. When using internal modules in conjunction with a decent build system like gulp-typescript you'll find that internal modules can cover lot of use cases where one would choose AMD/CommonJS in traditional JavaScript projects.
TypeScript gives you the freedom to decide yourself. If you need asynchronous module loading you are free to use AMD via external modules. You can also use CommonJS and/or use browserify to link together your code into a single file.
I've found that when you are a library developer - that is you ship your TypeScript compiled JS code to other developers - internal modules are a good compromise. You don't force your target audience (developers) to use any special module system like AMD/CommonJS, but instead ship isomorphic JS that runs in the browser as well as in node. Yet you still have a way of modularizing your code internally, just as AMD/CommonJS would allow you.
TL;DR: When you use TypeScript you get internal modules for free, and they provide you with a flexibility that would else only be achieved by AMD/CommonJS. Yet external modules still have their advantages. In the end, you should decide what is the best fit for your project.
TypeScript is a superset of JavaScript so its story is the story of JS, not of .NET or any other Microsoft product.
If you compile your TypeScript modules to AMD, then you load them through an AMD module loader like RequireJS (or Dojo, or curl) in your entrypoint HTML file, which can be as simple as this (using RequireJS):
<!DOCTYPE html>
<title>Application name</title>
<script src="scripts/require.js" data-main="scripts/client"></script>
(Assuming that your built TypeScript module is scripts/client.js.)
The Start page for RequireJS or the Dojo Introduction to AMD modules are both resources that can tell you more about how to load AMD-formatted modules in a browser.
You got a really good technical answer from C Snover, but the answer you're actually looking for is "don't use external modules". By external modules, I mean "AMD" or "CommonJS" modules.
If you actually need what external modules offer, they can be very useful, but they come at a significant cost in terms of build/deployment complexity and concepts that you need to understand.
Just because external modules are way more complicated doesn't mean they're better; the TypeScript compiler itself is written using internal modules.
You can convert an external module back to an internal module by omitting any export statements on the module itself (and by not having an export = statement at the end of the file either). For example, this is an internal module:
module MyLibrary {
export class MyClass {
public Foo = 1;
}
}
If you are using internal modules, all you have to do is reference them in the right order via script tags in your HTML files and they will work without having to deal with any sort of loader system.
<script src="MyLibrary.js"></script>
<script src="MyUICode.js"></script>
Issue: In a freshly generated MVC 5 web project I have the option to set Typescript's compile option to none, RequireJS, or CommonJS. This is a site-wide compile option.
In a particular view, I need to work with esri's javascript api. This api encapsulates both RequireJS and Dojo, and if I choose RequireJS as the typescript compile option, everything works fine.
If I want to use typescript anywhere else in the site I have one of two problems: either the JavaScript emitted is in RequireJS format (no RequireJS is loaded outside of the one view) or if I load RequireJS into the project, I get conflicts with the esri library.
For more background see my Blog Post
Question: Is it possible to specify individual page(s) compile using different options for JavaScript emission within Visual Studio?
One option is to break your solution into multiple projects. In one project you can configure typescript to use AMD modules.
A second option would be to turn off the compiling of typescript at build time by Visual Studio and set up a gulp or grunt task to compile your typescript. This way you can choose to compile one set of files with AMD modules and another without AMD and not have to break your solution into multiple projects.