foo.n should not autocomplete NaN. Does it ?
I don't remember what it is called, but it is the thing Atom uses most places for auto-complete.
It is not nearly as good as the Visual Studio auto-complete UX.
@danmane what other packages do you have ... that NaN is not ours
@danmane run
apm ls
Other packages can use autocomplete + provide suggestions as well :)
/usr/local/google/home/danmane/.atom/packages (8)
├── .bin
├── atom-typescript@6.0.1
├── autoclose-html@0.18.0
├── autocomplete-polymer@0.2.4
├── color-picker@2.0.11
├── editorconfig@1.1.1
├── linter@1.5.0
└── merge-conflicts@1.3.5
├── .bin
├── atom-typescript@6.0.1
├── autoclose-html@0.18.0
├── autocomplete-polymer@0.2.4
├── color-picker@2.0.11
├── editorconfig@1.1.1
├── linter@1.5.0
└── merge-conflicts@1.3.5
maybe it's autocomplete polymer
Thanks for the help :)
Btw, I greatly appreciate all of the software you've contributed for Typescript, as a frequent typescript dev it's aided me a lot over the past year. At this point seeing your name on a project gives me more confidence that I can depend on it, atom-typescript was a factor in my switching from sublime to atom
@wjswjs2
apm uninstall atom-typescript / apm install atom-typescript
however you probably want the latest grammar work that @Cu3PO42 's been doing, ... so fork? Or PR / Issue ... guess there is a user demand for it ... so would be okay with maintaining it
look at
atomConfig.ts in the repo ... if you create an issue I'll mark it up for grabs :rose:
@tcarlsen are you going to create that issue? Should I?
maybe splitting up atom-typescript into services (like autocomplete+ did) would be the best way?
but to answer your question,… You go ahead and create the issue :smile:
released
Hi folks, got a little question. I've lowercased the filename of one of my source files, now atom complains that this file is not listed in tsconfig.json but on save it compiles the file with old camel cased name to the output directory. Syncing files does not help, so is there a something like a cache I can additionally clear?
That seems not very robust...?
I'd like to use import from, but it seems like that's not compatible with the dts files produced by the typescript compiler
I'd have to manually edit those dts files I guess?
Hi, what are the best practices for writing a library in typescript that is then consumed by another typescript library? Is it really to manually ///<reference> the output file?
@CannibalVox No just use commonjs with declaration true. A quickstart : http://basarat.gitbooks.io/typescript/content/docs/node/nodejs.html