Migrate gulp process to include typescript - angularjs

I am updating the build process for an Angular 1.5.8 application, to allow development on Typescript.
After an over-complicated experience with Grunt, the current build process is simple and only uses Gulp and Browserify to build two bundles: my-lib.js and my-app.js. This way, the library, which is bigger, but more stable than my application code, doesn't have to compile so often and the compilation of the application-domain code only takes 0.1 sec. I am happy with that -- as well as the other developers.
Now we are looking forward to migrate to Angular 2.0 and want to start development in Typescript, but I'm not sure on how to integrate it on the build process and even the best approach on how to do it: should it be preferred to use tsc only to compile Typescript into Javascript and let Browserify handle the dependencies? Or should I use tsc as my main build tool and let it resolve dependencies, create mapping files and make the bundles?
Both Typescript and Gulp are evolving very fast and I cannot find documentation for this use on their documentations (1, 2). I would appreciate feedback from experienced people also working on the latest versions of these technologies.

Moving comments to answer:
We have doing very similar exercise at my organization, towards the end of it.
We have used webpack for most of the stuff, though webpack feels little grunt'y and after gulp, I am not a big fan of grunt.
We have used webpack to convert ts to js, bunding, minification. We have not used it yet for html to js string or css in js.
regarding the di part, you will have to worry about only js to ts. ts to js is not an issue as it is taken care by angular's string based di. regarding ts to ts, you will need to defined needed interfaces. Those will help you in moving those js to ts in future. Better to start with core components with least dependencies.
EDIT
Just to answer the part regarding the advantages of having gulp: specifically in the migration scenarios is, the upgrade is not going to happen in one go, so whatever is moved to TS should be handled by tsc and remaining by gulp.
Also gulp is much larger than just ts to js, we are still using it to create deployment package, inject js into html, fixing boostrap font paths, converting small images to base64, etc etc....

tsc has one purpose: to transpile (compile) typescript files.
gulp, on the other hand, is a build tool, which means it can run various tasks including compiling typescript, sass, minification, concatenation etc.
You can look here for an example on how to incorporate typescript and browserify using gulp: https://www.typescriptlang.org/docs/handbook/gulp.html
Another approach, is not to use gulp at all, but rather use npm scripts, you can see a sample here: https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-for-npm-scripts-3d6853dd22b8#.a7lwcmpaf

I believe the absolute simplest way to do this is to use Zwitterion. You can read this article for a quick introduction.
Zwitterion allows you to include TypeScript directly into the browser through normal script tags. All features of TypeScript are automatically available, because the code is transpiled server-side on a file-by-file basis as it is served to the client. Under the hood, it uses SystemJS to emulate the real ES module loader behavior that will be standard in all browsers. If you need this to work in production, you can create a static build with Zwitterion. All of this eschews bundling, so you'll have to decide on what your needs are for performance. Personally, I'm betting on performance not being that big of an issue with HTTP2, and I prefer the simplest of builds to the complication that webpack and all of its friends bring.

As you are moving forward with typescript, my recommendation would be to integrate any module bundler such as webpack (my favorite) Internally it will use ts loader to transpile the code. Also along with compile, you would be able to use ts lint for static code analysis (webpack would take care of it). Webpack also helps if you want to have multiple modules created. Try out yomen https://github.com/FountainJS/generator-fountain-webapp . Once scaffolded you can refer to generated gulp files. It would give you an idea about typescript integration.

The best way to do this without overengineering your gulp setup is to use the plain typescript compiler:
1. Install typescript locally(it won't conflict with your global tsc):
npm i typescript --save-dev
2. Add tsc as npm script(inside package.json).
"scripts": {
"tsc": "tsc"
}
3. Create proper tsconfig.json for your needs and put it in the same folder as package.json
https://www.typescriptlang.org/docs/handbook/tsconfig-json.html
4. Use tsc compiler directly from gulp
var child_process = require("child_process");
gulp.task("build", function(cb) {
var tsc = child_process.spawn("npm", ["-s", "run", "tsc"], {stdio: "inherit", cwd: __dirname});
tsc.on("close", function(code) {
console.log("Tsc finished with code", code);
cb();
});
});
Tip. Use https://www.npmjs.com/package/gulp-sequence and vote up :)

Related

how much advantage does a webpack created from scratch give?

I created an application using create react app, then I did the npm run eject command and I get a list of all dependencies. Yes, I do not have webpack config files, which will be if I create my own webpack. I see only one advantage that create react app adds extra dependencies that are not needed. All other settings, as I understand it, I can add the cra application to my own webpack. Can you please tell me why it is so important to create your own webpack? I just don't see much difference between builds. I have read a lot of articles and have not found objectively strong advantages can you tell me

Should we bundle shared component library separately in lerna monorepo?

I have three packages inside standard lerna monorepo.
client
react library
core
Core - is a shared component library with some utils (may or may not publish on npm).
React library is component library which will be shared on npm.
client is a bundled js library which will be consumed in browser with static html files.
core is a dependency in react-lib as well as client
Question 1 - How to setup core, should I transpile with tsc and bundle with tools such as rollup or vite (i personally prefer vite/rollup over webpack). or just leave it as is and import it in client and react-lib with absolute paths like 'core/src/*"?
Question 2 - can i build core in 'es' format and build client just like normal react app with either cra or vite. I tried this but i think i am missing something as final bundle doesn't seem to work in browser.
Any help would be really appreciated.
You have a few questions and I might not be able to answer them all but hopefully enough to guide you for the solution you're looking for.
Core - is a shared component library with some utils (may or may not publish on npm).
If you want to use Lerna then I guess you'll have to eventually publish the package on npm or a private repository. As an alternative, you could also use pnpm workspaces and their workspace: protocol which will allow you to link the packages in your workspace (monorepo) without ever downloading them from npm, for example if you use workspace:* then it will always use and link to the latest code from your local workspace. You could also use workspace: protocol with Lerna (or Lerna-Lite) since they both support it.
For your next Questions, I'll answer the last part of your Question 1 first because that affects the other portion of the question.
Question 1: ...or just leave it as is and import it in client and react-lib with absolute paths like 'core/src/*'?
Use absolute paths outside of the package is not a good thing to do since it will only work on your local project and you cannot publish that to npm since it will be broken for the other users. It's better to stick with the workspace and let the package use the main or exports entries defined in your package.json. In other words, it's preferable to always build/transpile and let your other package use the transpiled code and if you need to debug then make sure to also include sourcemap
Question 1: How to setup core, should I transpile with tsc and bundle with tools such as rollup or vite (i personally prefer vite/rollup over webpack)
It probably doesn't matter which one you use TypeScript, Rollup or WebPack, In one of my project I use TypeScript in watch mode, it will auto-transpile whenever you change your code, the downside is that the more packages you have then the more TypeScript threads are opened in watch mode (1x per package) but in your case if you only have 3 then it's fine, there's also this TypeScript issue that I'm following which will hopefully bring multi-threaded compilation in the future. You could also use Rollup and the concept would be the same, use it in watch mode for each package (I've done it with Vite/Rollup using vite build --watch
as explained in the next paragraph).
You can take a look at a project I've done Vue 3 and pnpm workspace using pnpm workspace with the workspace: protocol, it uses Rollup for transpiling and also uses Vite library mode which allows to bundle your library for distribution (on npm or others...), this allows you to bundle each package as a lib that is easily reusable by other projects. It's a Vue 3 project, so it's not a React project but it should give you enough ideas on how to do in React and it should help to answer your Question 2. Also that project is not using Lerna/Lerna-Lite but since it uses the workspace: protocol then it would be super easy to add Lerna on top of it in the future (basically just adding the lerna.json config should be enough)

What can't I export JSX from a NPM Package

I'm writing a library that exposes some React Components as part of its API.
I'm going to make a few assumptions here :
1 - It is going to be used inside react projects.
2 - Those projects will bundle their dependencies at some point.
3 - Those react projects can use JSX as a way of describing the UI.
4 - Their bundler of choice, Webpack if it's a create-react-app, will use babel in order to parse and transpile that JSX into vanilla JS.
Following that logic, I should be able export some JSX from an external package, because the package's code will be bundled, transpiled alongside the app.
However, when I do so in a create-react-app project, I get the following error :
SyntaxError: /Users/someone/Desktop/someproject/dist/esm/index.js: Support for the experimental syntax 'jsx' isn't currently enabled (35:13):
Add #babel/preset-react (https://git.io/JfeDR) to the 'presets' section of your Babel config to enable transformation.
If you want to leave it as-is, add #babel/plugin-syntax-jsx (https://git.io/vb4yA) to the 'plugins' section to enable parsing.
Yes, I could transpile the JSX, maybe I will. I just don't see any reason to, if it's going to be bundled anyway. I prefer leaving transpiling tweaking and optimisation to the user.
My concern is that if I transpile it myself, I have 2 choices.
import React in scope, and using babel to turn <MyComponent/> into React.createElement(), but this will rule out the possibility to use the new JSX transform
use the new JSX transform myself, and figure out whether or not my code will be compatible with react versions prior to 17. And increase my own bundle size because there is a lot of code added by babel to make that work.
At this point, I think I'm quite excited about this issue because frankly I have no idea why I can't just export plain JSX from my package. I know I'm probably missing something obvious, like a semi-colon or whatever, but I really want to understand.
If you want some code / rollup - babel configs feel free to ask.
Tanks !
Your logic seems to make sense at first glance. But let's examine why this is a bad idea.
JSX is a special syntax that must be transpiled down to the lowest common demoninator to be understood in the browser, or by Nodejs. This is what bundlers do, and as you mentioned, anyone working with react in a node environment is almost certainly using a bundler to do this.
However, there are any number of wierd syntaxes that people may use in their code. When a bundler imports code from a node_module, if the code in those modules is not already transpiled, the bundler would need to transpile them as well. Considering un-transpiled modules may be in any number of strange syntaxes, each module would need its own transpilation instructions (think babel configuration). Having unique transpilation configurations for every node_module would be very unwieldy, not to mention having to transpile each node_module, potentially in a different way, would be bad for performance.
The generally accepted best practice for solve this problem is to simply build your package using a bunder which boils the code down to the lowest common denominator. This enables your package-user's bundler to just bring in the code in a node_module "as is".
While its probably possible to come up with some crazy babe/webpack/rollup instructions to custom-interperet your module as JSX, do you really want your library users to have to do that? Especially in the case of people using create-react-app, customizing the babel config of CRA is not natively supported, which means they will need to take extra-steps to get your library to work. Additionally, webpack defaults to excluding node_modules from js transpilations for obvious performance reasons, and CRA follows this convention. When publishing libraries, you want them to be universally useable as easy as possible to consume.
Transpiling, tweaking, and optimizing code is best left to the person who wrote it, which in the case of a react component library you're trying to publish, is you.

What are the benefits of using webpack on electron?

I'm thinking about an app that uses electron, react and webpack. But I'm not sure if it make sense to use webpack on electron. I'm definitely sure that using webpack to the react part of an app could benefit a lot but I would like to know if it is the same thing with the electron part of an app.
Why do you need webpack for some cases even in node.js? Because CJS module resolution can cost a lot depends on your code:
https://twitter.com/samccone/status/1010584941355077632
Friendly reminder that Node startup time due to module runtime parse and compile is non-trivial. Illustrated below is the hello-world webpack common chunks example, As we can see the actual work takes < 1/4th of the time, the rest is lost to the javascript parse ghoul
This applies to Electron because it shares the exact same module resolution.
https://twitter.com/_ojkwon/status/933046538762207232
CJS without bundling
with webpack bundled
Still, it means development / deployment pipeline will change entirely, and this is not the guaranteed path of improving cost of module loading. You have to analyze your dependencies, and decide proper path for best performance.
Webpack is separate from electron. Webpack is used to bundle js files if you want to bundle your code together. There is a similar question that goes into additional detail here.

Client side app workflow

I'm trying to set up a client-side app workflow with yeoman (http://yeoman.io/), and as I'm coming from Rails background, I'm used to the niceties of the asset pipeline, which is backed by Sprockets (https://github.com/sstephenson/sprockets).
I'm struggling to make all the parts play nice with each other, and already spent a few hours trying to figure it out.
The first question that comes to mind is, is there a well established (e.g. convention over configuration, like in Rails world) way of developing a client side application with yeoman? Some definitive guide (besides the basic webapp-generator guide), perhaps?
Some suggest using requirejs (which I rather not use, because while it simplifies things in development, I'll need to jump through hoops to package the app (e.g. use Almond.js or AMDclean.js, or incur the unneeded overhead of requirejs).
My setup is:
Coffeescript, Backbone + Marionette, Handlebars for templates and ZURB Foundation with SASS.
What I'd like to accomplish in the end is the following setup, while using bower for managing the 3rd party dependencies:
In development:
Have something like Rails' manifest for javascript, so I can declare the order of dependencies, which will exploded into the the index.html
For all .scss files a .css entry added to index.html
Each file watched and compiled when needed
In production (dist):
All .scss files compiled, minified and concatenated to app.css
All bower files concatenated and minified to vendor.js
All application coffeescript files compiled, minified and concatenated to app.js
All templates compiled, minified and and concatenated to templates.js
index.html modified to include only those four files.
Is there something like this setup available?
I'm also open for suggestions and/or other alternative workflows.
Yeomam won't get you as close to a Rails workflow as you might expect. My two cents is that you take a look at something like Middleman has it does what you want out of the box.
Yeoman way
Using generators
You can use Yeoman generators and try to find out the combination of generators that will better suit the stack you are looking for, from what you describe I might take a look at:
webapp
backbone
maryo
At this point most of your requirements (both development and production) would be fulfilled:
a well defined project structure
compile coffeeScript and .scss
watch and compile
generators for model, view, collection, ...
compile and minify all files for production
You can use multiple generators to customise your own stack, every time that Yeoman detects that a generator overwrites a existing file it will prompt what to do, and you should be able to manage the conflict by yourself. Some framework-generators will obviously clash (it wouldn't make sense to try to use a angular generator on top of backbone).
Fine tuning
You can use sub-generators to scaffold more specific parts of your app, see Addy Osmani video.
Building generators
If you feel limited by some of the choices that a generator might impose (e.g. you prefer browserify instead of requirejs) you might want to fork a generator and add that as an option. You can even build a generator form scratch that will build your custom stack!
Grunt and Bower way
Yeoman is build on top of this two, but you can opt out at any moment and build your own stack using this two. You can add your dependencies through bower, and your tasks using grunt. There are plenty of examples that can give you some guidance, you could start with Yeoman webapp. There are also good examples at github like juanghurtado/puppeteer.
There are 3 files that you must keep an eye:
package.json — all you node dependencies go in here
bower.json — to manage the client dependencies
Gruntfile.js — here you define the tasks
Wrapping up
Maybe I'm stating the obvious but Yeoman does some magic work and helps you managing Grunt and bower, this magic only happens when you fully understand how this 2 work. So I would recommend that first you dive into some code and fully understand how Grunt and Bower work, and then you may use Yeoman magic.
Some other tools
You asked for some suggestions, here it goes:
gulp.js An alternative to Grunt. More you dive into Grunt more you will want Gulp (IMHO).
browserify An alternative to Requiere. Read this
assemble Static site generator for Node.js, Grunt.js, and Yeoman
Roman,
Answer for your first question, here is a guide on how to use Yeoman: http://code.tutsplus.com/tutorials/building-apps-with-the-yeoman-workflow--net-33254
If you want to use coffeescript by default, just pass the --coffee param
yo webapp --coffee
handling the assets order you can handle from the index.html file.
When you want to get the app ready for production just type the
grunt build
that will unify and minify all of your assets and throw it all dist folder.
To customise what you have in the build process you would have to write your own or customise the grunt build task, so that it will do exactly what you want.
Hope i gave you some useful information :)
Not an answer to my original question, but rather a pointer for someone who'd like to implement the same workflow I was looking for. I ended up writing a custom Gruntfile, using the grunt-injector to do the "explode the assets to the index.html" part, grunt-bower-install to add bower assets and configuring the grunt-usemin, grunt-contrib-concat, grunt-contrib-cssmin and grunt-contrib-uglify accordingly.

Resources