I currently have an existing project in Node.js and I would like to migrate it to a TypeScript project.
How can I do this?
Thanks for the help.
The easiest way to do this is to look at the Node sample provided with the TypeScript. It already includes declarations for the built-in NodeJS modules.
After importing the node.js you can start by converting your modules one by one. Since the Typescript will convert into JS, you can convert one file at a time and test it right away!
With ambients it should be easy to do! Good luck with your conversion.
Related
I need a easy way for preparing the environment for import x instead of require(x) in the express project.
I found only methods where I can do it manually, but I think this is not the best way that can be.
Is there any npm package or GitHub template that prepares the environment for this?
You can use .mjs file instead of .js file.
Documentation can be found here.
Or specify that you want to use module as the documentation shows
But for scallable application, you should use well structured code.
For example using, NestJS which is built with express out of the box. (It requires a minimal Typescript understand)
I work into a existing nodeJS project and I would like to use swagger codegen to automate the documentation.
Currently I write the swagger doc after to have code and there is always a time lag between dev and production....
I find two solutions. The first generate the node js projet and after you code inside, but my project have one year and lot of code...
The second solution is to write a syntax in my code and automate the documentation after with command line but this solution don't use yaml and my actual doc is to write is Yaml...
Thanks :)
If your existing node.js project uses Express as its web framework, you could consider using swagger-spec-express which would enable you to simply annotate your existing express api with swagger info.
Are there any limitations using TypeScript in a Node project compared to using Javascript at the server side for a web application?
Are all existing Node modules out there totally reusable without modification?
(PS: I am ok to use Visual Studio as the IDE.)
Are there any limitations using TypeScript in a Node project compared to using Javascript
No. You just have the overhead of setting up TypeScript, for the sake of its advantages : https://basarat.gitbooks.io/typescript/content/docs/why-typescript.html
Are all existing Node modules out there totally reusable without modification?
Yes. Just set allowJs:true in your tsconfig and you don't even need a declaration file.
Can someone give me some advice or links for discussion on whether I should bundle JS for backend?
I tried to Google with this title (and similar words) and I can't get any useful links.
Just want to know, say I am using latest Node.JS (es6-ready), should I bundle/compile the JS? If not, how am I suppose to use typescript/flow?
Thank you.
I feel like you are asking two different questions. I'll try to answer both.
How can I just run TypeScript code?
This is the one your question's title seems to ask ("How to use typescript/flow in nodejs without compiling it"). For this, you can use the ts-node package on npm. But it's usually not a good idea to use ts-node over just compiling when running in production because it tends not to be as fast.
How should TypeScript code get distributed to be run?
Any TypeScript code will need to get compiled from .ts files to .js files to eventually be run. Basically something like the same thing applies to Flow code.
If you plan to distribute a package written in TypeScript, you should be publishing the .js and .d.ts files together. This is so that
Your package consumers don't have to recompile your package. (they already get .js files.
Your non-TypeScript consumers don't need to install TypeScript to use your package. (they already have runnable .js files)
Your TypeScript consumers can get good type safety and completions. (they get your .d.ts files)
For more information, see the TypeScript documentation on Publishing Declaration Files.
I am currently working on two related projects. One is a Phoenix based website and API, while the other is an Angular2 application that among other things uses the API provided by Phoenix. I now want the Angular2 application to be used by the Phoenix project. The problem is that I don't know what the best approach is. I am very new to Angular2 and NPM, and know very little of how it actually works outside of basic usage. These are the ways I can think of solving my problem:
Put the Angular2 project into the Phoenix project, making it one project. I have no idea how to do this, but I will probably get there through trial and error as both use Node.js so it should be doable.
Publish the Angular2 project to NPM, and then import it to the Phoenix project. How much work would be needed on the Phoenix side? Would it be the same as just running the index.html in the Angular2 project? Would I need some kind of Angular2 "shell" around it?
Run the Angular2 application as it's own thing, and just link to it through the Phoenix website.
Importing it as a node module sounds like the best approach, but can it be done for full applications, or is it intended for support libraries only?
I am unsure if this is the "right" way to do it but this is what I did in the end:
I compiled my entire Angular2 project into app.js, vendor.js, and common.js, I then moved it all to web/assets/. After that I simply created a new html and referenced the files in question.
The biggest challenged was finding something to compile it all into these 3 files. I ended up using a stripped down version of: https://github.com/AngularClass/angular2-webpack-starter
I think you would want to leverage brunch.io, which ships with phoenix to handle your front end dependencies. There are skeletons which are essentially templates that create different front end configs but I don't see one that provides angular2. In this case I would say use bower to install the js packages you want ie:
bower install -S angular2
With this you can use brunch as a processing pipeline and it will handle minification, linting etc. and you will still be working within the "recommended" approach to managing front end assets in Phoenix.