How to see the ES6 code of a 3rd party library - node.js

Sometimes I would like to observe the original ES6 code of a 3rd party library - one of those I mention in the package.json, but all I see is probably the ES5 code after Babel transpilation.
For Example:
In the code when I do:
import {CardHeader} from "material-ui";
And then trying to "go to Decleration" in the IDE I see transpiled code that means nothing to me.
Is there a way to see the original ES6 code?

To be honest, I've noticed the easiest way is usually to google the source.
Googling "github material-ui cardheader" leads me to https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/CardHeader/CardHeader.js which looks about right...

Related

Grunt still unable to handle ES6 imports?

I am working on a project under NodeJS that uses ES6 imports/exports (hence having set type: module in its package.json) and want to automate some tasks using Grunt. Now, I absolutely love grunt, but it appears to me that even in 2022 it is still not able to work nicely with ES6 modules? I always get an error saying "require() of ES Module /vagrant/Gruntfile.js from /vagrant/node_modules/grunt/lib/grunt/task.js not supported."
I understand where this is coming from, and I do understand there are workaround options - in particular, renaming Gruntfile.js to Gruntfile.cjs and passing it to grunt with the --gruntfile command line option. But that is incredibly annoying - it makes the command six times as long as it would be if I could just run grunt and be done with it. Pretty much the same goes for transpiling with something like Babel: That is exactly the kind of thing grunt is intended to handle in the first place, so it feels a bit like the horse riding the jockey. I feel like this should "just work".
Am I missing something here, or is grunt really unable to handle ES6 imports out of the box?
Actually, looking at the grunt github page it appears that a recent commit has addressed it.
I guess this issue will therefore be resolved in their next update.

Make Typescript node modules work together

Has anybody got a setup working in which module 1 using typescript is referencing another module 2 also with typescript and both use tsd types such as node.d.ts ?
I have no problem compiling both and using them, as long as i simply require module 2. But as soon as i use import instead, i get into duplicate identifier hell, due to the fact that source files in both modules import e.g. node.d.ts typings from obviously different paths. Classes in both projects use e.g 'streams' or 'lodash' thus both use them in typings and thus use the /// reference syntax. The tsconfig in both projects excludes typings.
Typescript has come a long way since this was asked, and it's now much easier. You can link the proper files in package.json:
{
"main": "library-commonjs.js",
"module": "library-es6-module.js",
"typings": "library-commonjs.d.ts"
}
main is used by packages using CommonJS and Node.js module resolution. module is used by packages supporting ES6 imports. And typings is followed by Typescript (currently Typescript 2.2) to resolve type definitions for the package.
After struggling with this, I spent some time creating a typescript boilerplate/starter project that demonstrates how to do it properly:
https://github.com/bitjson/typescript-starter
That project includes a lot more documentation, and several examples of how to import code from typescript projects.
EDIT: With TS 2.2 this has gotten quite a lot better. See the accepted answer.
It seems this is not really possible yet in typescript 1.8.x. But they seem to work on it via https://github.com/Microsoft/TypeScript/issues/7156.
Also the problem is supposedly mitigated by using a jsconfig.json which should be used by VScode (see https://blogs.msdn.microsoft.com/vscode/2015/07/06/visual-studio-code-es6/). Sadly i didnt get it working yet.

How to use webpack components

Due to the lack of support of modules or packages under development in npm I have decided to use webpack's components which from the look of the example provided here webpack/examples/components seems to be exactly what I am looking for. However there is no example how to actually use the example. Drawing from webpack's convention I thought that:
webpack/examples/components> webpack component.json > bundle.js
would do the trick but nope I get an error. Tried some other stuff like putting an entry file and an output file in the webpack.config.js but no luck there either. Has someone ever use it, does it work and most importantly how to start it?

Typescript - Further Exploration into "require" and paths

I had resigned myself to the fact that every require statement in Typescript had to be relative to the file you were typing in, but I recently discovered an application that does this differently and it confuses me. I was hoping someone with enough skill could explain how this is working to me.
The application in question is the new Raven DB HTML5 Studio, which uses typescript, you can find the whole application here:
RavenDB HTML5 Studio
When browsing its source code, I came across something interesting... if you go and look at many of the files; In specific the one I am looking at... app/viewmodels/deleteItems.ts, it has a reference at the top that reads..
import document = require("models/document");
but models/document isn't a path relative to deleteItems.ts, but this works. Can someone explain how this is happening? I'm linking you RIGHT to the exact files I'm talking about. This kind of behavior is littered all over this application.
app/viewmodels/deleteItem.ts
app/models/document.ts
This is exactly the kind of behavior I really wanted to try and emulate in my own code, since trying to keep all of the paths relative to the file I'm working in is a headache, but this program seems to be completely free of that requirement.
This doesn't necessarily involve RavenDB, but I am tagging it anyway, because perhaps someone who has read over the Raven repository will understand it and be able to answer.
Update
I am trying to mimic this behavior in my own code, and not finding any success. I am sorry if I seem outright stupid, but this is all really confusing me. Here is what my structure looks like; My repository is private, so I cannot really just link to it.
app_content
scripts
home
controls
models
editors
utils
UserControls.ts
UserMapping.ts
UserElements.ts
ui
lib
jquery
jquery.js
jquery.validate.js
jquery.ui.js
kendo
kendo.all.js
kendo.aspnetmvc.js
// other libraries
Alright, that's a general feel for my folder layout. All typescript files are under the /home folder so that I can prevent github from saving their compiled javascript and locking that.
So then, in the file UserControls.ts, it looks like this right now...
import userElements = require('./UserElements');
import userMapping = require('./UserMapping');
export class UserControls {
// code
}
No matter what combinations I have tried, this is the only format/syntax that doesn't throw errors in Visual Studio. But from what I see in the RavenDB project, I should very much be able to declare it like ...
import userElements = require('utils/UserElements');
import userMapping = require('utils/UserMapping');
export class UserControls {
// some code
}
No matter what combinations I have tried, this is the only format/syntax that doesn't throw errors in Visual Studio. But from what I see in the RavenDB project, I should very much be able to declare it like ...
That is because they are using a drandalJS configuration to tell it how to resolve the file path. (see https://github.com/ayende/ravendb/blob/New3/Raven.Studio.Html5/App/main.js)
There isn't a similar configuration (basePath) for TypeScript at the moment. Your best option is to use relative paths as you've already noticed.
PS: an old but still relevant video that shows you how requirejs config works and relevance when using TypeScript https://www.youtube.com/watch?v=4AGQpv0MKsA&hd=1
The TypeScript compiler's module resolution algorithm is essentially undocumented, unfortunately. It tries to "split the difference" between AMD and CommonJS's module resolution rules, so it's somewhat hard to reason about.
What you're seeing here is an attempt to mimic CommonJS's "walk up the tree" resolution rule. When in the path C:\a\b\c\d resolving x, first C:\a\b\c\d\x is tried, then C:\a\b\c\x, then C:\a\b\x, and so on until it hits the root folder and gives up.

How to set up typescript 0.9.5 in Visual Studio 2012

I'm trying to write a game in Typescript but I am having a hard time setting things up.
I am using visual studio 2012 and I installed typescript 0.9.5.
What I want is to build an app/game like I would in C# or AS3, meaning using putting classes in seperate files and using modules to seperate/connect code. This would then compile to either a single file or some kind of require.js like solution (which I'm also not clear about).
But I have done a lot of research and ran in to a lot of hurdles.
-There are a lot of references to calling something like "tsc greeter.ts" but when I use this in the visual studio command window I get back "Command "tsc" is not valid." I tried adding the tsc folder to environment variables path, but this didn't change anything. So I can't really run it. Also I don't understand how tsc would know where greeter.ts is located.
-I'm confused between the "///" and the import statement. How do these factor in the structuring of an app?
-It seems there are a lot of ways to make a typescript app, which all have different requirements and code style and structure. Is there no standard way, or am I just mistaken and is there a good way to approach this?
So the main question is: How do I build a typescript app/game structured like a c# or AS3 app?
To answer just some of your question, you no longer need the /// reference like this:
/// <reference path="../typings/jquery.d.ts"/> This was used in earlier versions of typescript, however now it will find any typescript files in your project for you.
I don't think there is a 'standard' way to create a typescript project any more than there is C#, there are many design patterns and you will have to research the pros and cons of both and choose one.
You should also no longer need to run "tsc greeter.ts" to compile your code. It will compile on build of the project.

Resources