I want to use typescript in ES6-compatible mode, as a partial replacement for ES6 classes, because it is quite convenient and clear compiler, comparing to traceur/sweet.js macros.
How can I compile files with .js extension?
tsc src/util.js gives error TS5007: Cannot resolve referenced file: 'src/util.js', whereas tsc src/util.ts works just fine.
There are both util.js and util.ts in src directory, but I don’t want to have any .ts files.
You can't. It is intentionally not supported by the TypeScript compiler so as to avoid confusion for beginners.
However you can use the typescript compiler api, pass in your content and get the output you can write to file yourself.
There are plugins for grunt/gulp builders: gulp-typescript and grunt-typescript, which can make any sources, even non-.ts compiled with typescript.
Gulp-typescript implicitly uses typestring, which compiles any string with typescript code, and which is just a wrapper for the typescript.api - node.js API for typescript. Unfortunately, gulp-typescript is not fully complete - no errors logging, no compiling options, so you might need to use typescript.api straightaway.
Related
According to the Webpack documentation https://webpack.js.org/guides/getting-started/
Webpack is used to compile JavaScript modules. Once installed, you can interface with webpack either from its CLI or API.
But what does compile in this sense mean? JavaScript clearly isn't a compiled language so how can Webpack "compile" JavaScript modules? Should't it rather say bundling instead?
Webpack isn't a compiler it's a bundler, but like a compiler it parses your source files, Webpack bundles your code and you can set it up in a way that it also transpiles (transforms) newer JS syntax into older but more widely supported syntax and it also allows you to split your code into different modules using commonJS or es6 modules and bundle them together in a way that will make them work inside a browser in other words it compiles "source" (doesn't work in browsers) to "target" which is bundled and can be parsed as one program.
also most JavaScript engines nowadays use Just-in-time compilation meaning that JS is a compiled language, it's not compiled ahead-of-time but the engine parses your whole JS file then compiles and executes it chunk by chunk.
Can't quite figure out why I'm not getting intellisense for ES6 features in a TypeScript file.
I'm fairly certain it is related to the lib.d.ts file that is used in the typescript source files. For reference this is located in:
C:\Program Files (x86)\Microsoft VS Code\resources\app\extensions\typescript\server\typescript\lib
I noticed that the same folder contains lib.es6.d.ts. When going to definition on a method that is defined by the base interface definition files, it points you to lib.d.ts and not the es6 version. The es6 version has all of the interfaces that I need.
That said, even if I include some ES6 methods and force the task runner(which under the hood uses the typescript compiler installed), it doesn't transpile to ES5 like I expected it to.
Maybe my TypeScript compiler version is dated? Primarily I want these features:
Symbol
Array.prototype.includes
String.prototype.includes
I see these interfaces defined in the es6 typing definition file. Is there a way to get VSCode to recognize this? I'm thinking a hacky approach of just including that lib file in my project but I'm trying to avoid that and in the end it still doesn't solve my problem when I transpile to ES5 and get garbage.
Thanks and much love :)
I was trying to use TypeScript with WebPack. Ts-Loader was working fine till I use Materializecss. It is not having TypeScript binding. Which I felt ok as there are very few JavaScript things and I can use it for UI purpose by doing type casting with any. Code works but Web-Pack is not adding Materializecss JavaScript files in compiled file. As, I am not importing it in TypeScript file.
I can't import it as it is not having definition file for TypeScript.
So, currently I have to fallback to Gulp + Bower approach. It is ok for now but I am missing npm approach that is better for bigger applications IMHO.
Let me know if any further details are required.
I am starting a new Web project and trying TypeScript, mainly as an ES6 transpiler but also with the additional benefits of type checking, especially for existing libraries such as jQuery combined with the DefinitelyTyped type definitions.
Since the latest version, TypeScript supports both its own internal modules and ES6 modules, which calls "external" modules. Because ES6 is more standard than TypeScript, my intention is to use ES6/external modules rather than the traditional/internal TypeScript modules.
I have my own code defined in several files/modules, but I want the build to generate a single .js file that I can load from the browser.
The problem is that as far as I can tell, TypeScript is only able to generate a single output file when using its own module format. If I try to use ES6 external modules, then it generates a separate .js file for each .ts file.
This means I would need to concatenate them using browserify, but also I want source map support, which means that I should configure browserify for input and output source maps, then combine it with exorcist so the source map is extracted out of the bundle.
That looks like a very complex build setup. Isn't there a more straightforward way, maybe directly supported by TypeScript? What is the best approach? What do you recommend?
Let TypeScript do what it does best...
Add types to JavaScript be it ES5/ES6/ES7
Transpile to ES5
Resolve modules via the specified module syntax (commonjs, amd, umd, system)
Then find another tool that will take the separate files and combine them into a single bundled file (in the right order). My suggestions are to look into:
webpack
browserify
tsify
Are you looking for a solution in the browser? If so, I highly recommend my project Zwitterion. It removes the complicated build steps, and let's you include TypeScript directly into the browser with normal script tags. You can also use standard ES modules directly, with no extra setup. It uses SystemJS under the hood to achieve that. There is no source map support yet, but that should come. If you would like more information besides what's in the README, you can read "Zwitterion, forget the build step".
I have a library that I'm building in TypeScript. I'd like to include this library in both TypeScript and JavaScript Node projects. What is the general strategy to do this? Should I compile and have two versions or is there some other strategy I should be using?
I'd like to include this library in both TypeScript and JavaScript Node projects. What is the general strategy to do this?
Compile with the following to get the js output:
--module commonjs --outDir ./dist
This should make your project consumable by JS projects. To make it consumable by TS projects you need to generate a declaration file. This can be done using https://github.com/SitePen/dts-generator See usage for details : https://github.com/SitePen/dts-generator#usage
Note: There is discussion on removing the dts-generator dependency : https://github.com/Microsoft/TypeScript/issues/2338
In most cases I have seen you have a /dist/ folder where the compiled JavaScript is located.
Usually there is also a minified version like yourfilename.min.js - the rest is either outside or in a /src/ folder, so outside you have only the license/readme.md, package.json left and maybe the file for Grunt/Gulp (it is considered polite to - if you use a taskrunner - include a Grunt/Gulp file for compiling the typescript and minify the .js file afterwards, as far as I got it)
If you want to preserve the TypeScript advantages when using it in TypeScript projects, then you obviously have to expose a TypeScript version of the code so the TypeScript compiler can see the TypeScript declarations for your interface.
But, if you want people to be able to use your library in plain Javascript projects (that don't compile TypeScript into JS), then you have to offer a version that has a plain Javascript interface and where the code has already been compiled into plain JS.
So, if you want both of those advantages, then you have to offer two separate versions. The plain JS version can obviously just be a compiled version of the TypeScript (compiled into plain JS).