I have a question regarding following TypeScript plugin for SystemJS :
https://github.com/frankwallis/plugin-typescript/
Here is its description
A plugin for SystemJS which enables you to System.import TypeScript files directly. The files are compiled in the browser and compilation errors written to the console.
I wonder what would be the use cases of such plugin.
Why would developers import directly ts files and compile them in the browser instead of compiling them during development and import js files ?
Won't it reduce performance and load time to do it in browser ?
Is it supposed to be used only in development environment ?
plugin-typescript author here. In-browser compilation is strictly a development tool, in production you would use systemjs-builder (in combination with plugin-typescript) to create a single file containing all of the transpiled javascript.
Since the plugin was originally developed, a number of new workflows have become available when using typescript & systemjs (typescript single-file transpilation, vscode, systemjs hot-reloading, typescript system.register output, to name a few...) - Which one is right for you will depend on the size of your application, the platform/server you are using, and your own personal preferences.
No one in their right mind would compile/transpile in the browser for production; it's the equivalent of sending a turtle to get your mail because you don't like walking.
This is strictly a development tool for helping TypeScript devs avoid having to constantly compile after every change, with the added benefit of providing features like hot reloading.
Related
I have a couple of Angular UI libraries used in many applications. These libraries have more than 50 modules in them but the applications usually do a barrel import. I want to analyze their production bundle and find out which of the modules are used in the build.
When I use source-map-explorer or webpack-bundle-analyzer I get to see the library's root module only, is there any way from there to drill down further? Alternatively, I am thinking of creating a custom decorator in the library to print a message to console when used but the drawback I see is that the message will appear only on runtime not from build.
Is there a good way to derive this statistic?
I am running on a huge project with thousands of .js files that are written in es5, and for many reasons and benefits of TS, we've decided to start migrating to TS, after a couple of days and many pieces of research, I am going to elaborate a couple of points:
To start migrating from es5 to ts we can start either by two ways:
First way:
1- Installing ts, creating tsconfig with allowJS set to true then start changing the extension of files to .ts and everything will work by default
2- As we want to migrate gradually we don't want at once to replace the global scripts to native modules, in other words, we don't want immediately to type import and export, but instead we want to keep the old way global scripts and use /// <reference path=""> to load dependencies
3- after previous step we can gradually start turning the files into native modules esm
Second way:
1- As I've read about UMD it will work on both borwser(client) and server, which means support all type of modules AMD, CommonJS, SystemJS and Native ES modules
2- after re-writing the scripts in UMD fashion, we can gradually start moving our scripts to ESM
last but not least, and regarding the intelligence we'll start writing .d.ts files accordingly or we can rely on ts-loader to generate the files
lastly, we either go with ts-loader or babel but we are not sure if there are couple of limitations for each of which
Any idea is really appreciated on what is the best way to start migrating
Maybe this tool can help you:
https://github.com/airbnb/ts-migrate
ts-migrate is a tool for helping migrate code to TypeScript. It takes a JavaScript, or a partial TypeScript, project in and gives a compiling TypeScript project out.
ts-migrate is intended to accelerate the TypeScript migration process. The resulting code will pass the build, but a followup is required to improve type safety.
If possible, start fresh and write migration script which does copy/paste task of code. In which Project setup will be error free in term of compile/build/run/lint. So even in future there won't be any issue you just need to add modules. You can migrate module by module.
Now if you are migrating to TS means not just by extension or package type, because it won't benefit more, you will need to change in code like types, interfaces, configs etc.
So starting a fresh project and then converting code to TS and then gradually moving should be better.
I would suggest you should write new modules in typescript and slowly convert existing files and modules to typescript. But keep the output in js only. Convert each ts file into js, For e.g, if you have a module Utils create two folders inside this ts and js. Write a build script which will convert ts to js and move inside the js folder. This way you will be converting all files into ts. For import/export you can start it for the new module. I have done the same in one project.
Regards,
omi
I appreciate all the answers but for my case it is so complicated because ts modules will affect the scope, what I found useful is using what so-called shimmer modules in webpack which allows a feature called imports-loader which I can use to manipulate the scope of js, hence nothing is broken, then I can move file by file to start migrating
I'm building node/Express application and want to utilize 'latest and greatest':
node/Express + TypeScript + webpack.
Question: What are the benefits of using webpack to bundle all my nodejs code into one file? Just trying to understand if it is an overkill to use webpack for such purpose.
I think the biggest win you will get with Webpack would be Hot Module Replacement (HMR).
During development, if you were to use a tool like nodemon to watch for file changes you would have to wait for a full restart of your node application, whereas with Webpack HMR it will only update what is changed speeding up your development process. The upfront costs of setting up Webpack definitely payoff over the course of development.
Webpack also gives you the ability to use loaders. In your case using TypeScript you would likely want to use the ts-loader to transpile your code into standard javascript code that is compatible in your node environment.
Good that you're using the good combination of languages at the server-side.
First of all understand why should we use Webpack.
Webpack is used for module bundling by the builds we’re generating. As a best practice, we should not run the source directly.
Also, there two common modes available by default in webpack are,
Development
Production
Development build produces source map files and it’s not minified and uglified. It holds the information about the source files and even it is compressed and compiled it is easy to debug the development build.
FYI, my development build file size is just ~51KB since I use mongoDB in my stack.
Production build compresses our source code into a minimized single file but performs the same task as source code does. It won’t produce source map files and it’s uglified and minified so the debugging is not possible. My prod build file size is just ~9KB.
Notice the size difference after the file compression from dev to prod.
So, I recommend to use webpack not only for bundling, also we can configure transpiler options using loaders in it.
Note: Webpack can be used for both Client and Server side.
Happy Coding!
I am looking to work on an Angular2 datepicker component as if for release and inclusion in multiple projects. What is the best way to structure the project for this compared to a regular Angular2 project built with angular-cli? Are there any examples of good starter projects/seeds for such a task? Or should the component library actually be an angular2 application itself?
My initial assumption was that I could just create a standard project with angular-cli which has a single module (e.g. MyDatepickerModule) which contains a hierarchy of components forming the datepicker however I don't know if this is the best way as I don't need everything that a full application provides.
Thanks for any guidance!
I would publish the library with AoT compatibility in mind.
This means compiling the source using the ngc compiler. In the distribution package I would publish the JS source, original html/css files, d.ts typings files and the ngc generated metadata.json files.
I recommend publishing the JS source with es2015 modules since this will make your library tree shakable. I would target es5 JS, but with es2015 modules . TypeScript allows for this hybrid mode by setting module to ES2015 and target to es5 in tsconfig.json.
Publishing these files will make your library AoT compatible and Tree shakable.
This is all the consuming application needs in order to AoT compile your library into their complete application.
It's not recommended to publish TypeScript in your package since this would require the consumer to replicate your build environment (typings + TS compiler version).
You can also publish a JiT compatible umd bundle with inlined templates and css. This can be helpful since it might not be practical do AoT during development since compilation is a bit slow. The umd bundle will make it possible to use your library in a JiT based dev environment. For production though you should definitely use the AoT version.
The CLI is not ideal for publishing libraries since CLI is primarily a tool for building complete applications. They might support libraries better in the future though.
Check out https://github.com/angular/material2. A work in progress, it's a library of controls and themes for Angular2 applying Material Design and is an excellent source for learning to build your own control library.
If you code an application using ES6 modules and classes, is there any need to use a module loader framework, or is the best practice to just use a build tool to concatenate all the code into a file (or files) and include those using a normal script tag?
Yes. Somebody, somewhere along the line has to load the module.
I think you're conflating compiling modules ahead of time vs loading them individually. Webpack is a module loader that outputs a single file for the browsers to use later, while the System API and requirejs et al load a number of individual files.
There are performance factors on both sides, particularly longer build time (when precompiling) vs longer load time (with multiple files).
Webpack, Browserify, and most other module loaders (with the notable exception of the System API) allow you to define some loaders for certain file types and automagically compile your (S)CSS or templates on the way through, as well as running other tools to uglify or obfuscate your code. The ES6 System API does not provide these features, but is a more robust runtime loader than most.
This boils down to two trade-offs:
support for non-JS modules (styles, templates) vs build time
single request and longer build vs many requests and short/no build
Evaluate them for your users (high-bandwidth vs mobile), environment (if you have two dozen CI agents, who cares if the build takes an extra 3s?), and stack (if you have a lot of template files, compiling them AOT could be important).