Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 29 09:12

    basarat on master

    Update README.md (compare)

  • Jan 21 23:27
    basarat opened #653
  • Jan 21 23:27
    basarat closed #589
  • Jan 21 23:27
    basarat closed #588
  • Jan 21 23:27
    basarat closed #587
  • Jan 21 23:27
    basarat closed #581
  • Jan 21 23:27
    basarat closed #580
  • Jan 21 23:27
    basarat closed #575
  • Jan 21 23:27
    basarat closed #573
  • Jan 21 23:27
    basarat closed #569
  • Jan 21 23:27
    basarat closed #564
  • Jan 21 23:27
    basarat closed #560
  • Jan 21 23:27
    basarat closed #511
  • Jan 21 23:27
    basarat closed #479
  • Jan 21 23:27
    basarat closed #461
  • Jan 21 23:27
    basarat closed #446
  • Jan 21 23:27
    basarat closed #439
  • Jan 21 23:27
    basarat closed #292
  • Jan 21 23:27
    basarat closed #260
  • Jan 21 23:27
    basarat closed #232
Michael Billing
@mfbilling_twitter
@basarat great choice with Monaco - I like your bold fork strategy goal - never at bad idea to be ambitious, you can pull it off :)
Ben Dornis
@Buildstarted
finally got the basic project set up iwth alm. nodejs is really confusing with all the modules and what not
Basarat Ali Syed
@basarat
:rose:
Ben Dornis
@Buildstarted
i'm wondering if some of the features i'd like to see in alm will be resolved with the move to monaco...
Ben Dornis
@Buildstarted
and by "see" i mean contribute :)
Basarat Ali Syed
@basarat
@Buildstarted monaco is not without its flaws. A small sample : https://github.com/Microsoft/vscode/issues/created_by/basarat :rose:
@Buildstarted I've been working hard here : https://github.com/basarat/monaco
@Buildstarted The monaco API is still in flux. Once its more stable / mature I'd love to see contributions :rose:
Ben Dornis
@Buildstarted
most of what i'd like to contribute right now are keyboard shortcuts - i'm thinking if it's a separate "module" it'll probably work for monaco and the codemirror editors - just didn't want to duplicate the work if the shortcuts exist in monaco already :)
Basarat Ali Syed
@basarat
codemirror had a nice keymap => command path. Meant it could easily be done externally. Monaco is harder nut to crack. In fact they didn't even export the ability to register actions (what codemirror calls commands) by default : see Microsoft/vscode#7382
@Buildstarted I had to do all the work in https://github.com/basarat/monaco e.g. https://github.com/basarat/monaco/blob/49bd935a0d2dae72b5c6e8447791148b95a1b771/extensions/preBuild.ts#L224-L237 since I couln't figure out a better way :rose:
i.e monaco is not very friendly to user customization ... understandable considering I seem to be the first external user :rose:
Jari Pennanen
@Ciantic
testing first time alm tools, looks great. Intriguied with the fact I could serve this editor from my server directly
first problem I encountered is a list of files in Ctrl+P, there is a lot of stuff I would not want to see, e.g. node_modules/ and .awcache/ etc.
what I don't understand is why this is so much faster than vscode file search, it must be really poorly optimized compared to this
Basarat Ali Syed
@basarat

first problem I encountered is a list of files in Ctrl+P, there is a lot of stuff I would not want to see, e.g. node_modules/ and .awcache/ etc.

@Ciantic instead of file search (which shows everything) you can use project file search (which only shows you the TypeScript files in the compilation context!) https://basarat.gitbooks.io/alm/content/features/omni-search.html#project-filepath-search :rose:

what I don't understand is why this is so much faster than vscode file search, it must be really poorly optimized compared to this

@Ciantic we basically index it up front (as everyone uses file search inevitably) and in a seperate process. That makes it faster : fileListingWorker : https://basarat.gitbooks.io/alm/content/contributing/async.html :rose:

Gerasimos (Makis) Maropoulos
@removed~kataras
Hello to all
@basarat is the monaco version ready so fast? :!
Also keep note that we have some iris' users who are willing to help on ALM (they learnt it from iris) I will send them straight to you at the next days :P
Basarat Ali Syed
@basarat

is the monaco version ready so fast? :!

I would say that its fully functional. But not to the standard I want. So will be a while before I release to the world :rose:

Also thank you so much for your efforts :heart:
Basarat Ali Syed
@basarat
blasterMonaco.gif
The code blaster ported to monaco ;) :rose:
Gerasimos (Makis) Maropoulos
@removed~kataras
ooho
nice!!!
I thanks you for ALM. Is early to tell but something inside me knows that it will be the most succesfully complete tool for typescript
and typescript is used by most and most people everyday
and focus on reactjs as you already do as I can see :)
Jari Pennanen
@Ciantic
@basarat Ctrl+P is Omni search (files), I think it should have some ignore possibility also, seeing a lot of hexadecimal hashes from cache directory seems unneccessary. It's also more convinient shortcut, which people are more familiar with, thus it's their first experience.
one possiblity is to switch shortcuts around
cause I can see a use (rarely) for whole directory wide search from within node_modules also
also, looks like the alt+ctrl+y can't find SCSS files
(I'm still not sold on free style, I would rather have type providers and get type safe suggestions for classNames)
partly because I've memorised the emmet and other things, that makes using LESS/SCSS/CSS files so much more convinient for me
Basarat Ali Syed
@basarat
@Ciantic completely agree. So many times I press ctrl+p and wish I'd ctrl+shift+y. I'll change them around a bit
@Ciantic about scss ... I am not entirely sold on free style either. But using pure css in simple enough for me. Generally just require('./foo.css'). That said I am sure that eventually css will be obsolete for TS / React projects and thus I'm focusing on a great TS only experience :rose:
Jari Pennanen
@Ciantic
Btw, I think you might like this:
// Images.ts
// Faux types to achieve type safety at assignment
export declare class ResourceImage {
    type: "resourceImage"
}
export declare class ResourceIcon extends ResourceImage {
    subtype: "resourceIcon"
}
export declare class ResourceBigIcon extends ResourceImage {
    subtype: "resourceBigIcon"
}
export const closeIcon: ResourceIcon = require("./close-icon.svg");
export const someOtherIcon: ResourceIcon = require("./some-other-icon.svg");
// ... list of all images

// Then use like this
import { ResourceIcon } from "./Images";
export class Button extends React.Component<{
    icon?: ResourceIcon
}, {}> {

}

// This forces the users of the Button to import icons
import { closeIcon } from "./Images";
<Button icon={closeIcon} />
I find this neat, if I'm not mistaken, it also allowes the Webpack 2 to prune icons that are not being used
and of course, it allows to see all references of the icon
Jari Pennanen
@Ciantic
(not sure why I used declare class, inteface seems just as apt)
Basarat Ali Syed
@basarat

it also allowes the Webpack 2 to prune icons that are not being used

Probably true . But only if it prunes unused vars

This forces the users of the Button to import icons

Users will not get a good error message though. and they can give it {type:'resourceImage',subtype:'reousrceIcon'} object instead of an actual icon (at least thats what the error will guide them to)

I prefer enums + a map of enum => value for such things. Of course it isn't pruned.
Marinho Brandão
@marinho
hey! just knew about Alm, loved it and got a couple of ideas to do with it: my major expectation is to setup some sort of self-hostable Plnkr to try some stuff out that cannot go public.
so, does anyone know how to hide some folders (i.e. node_modules) from the tree? the main reason for now is performance, but if could be for other reasons too. EditorConfig doesn't have any key about it.
Basarat Ali Syed
@basarat
@marinho no option about it. I actually like seeing node_modules (and quite commonly open and edit them to fix some thing before sending an upstream PR). What is the performance problem you are having ... there really should be no performance issues and that is something I should fix :rose:
Nothing major slow anyways :)
Marinho Brandão
@marinho

@basarat, actually it's only about the first load on the tree that annoys me. The project I work is an Angular 2 app with multiple components (a few hundreds, maybe) and the list of dependencies in node_modules is something of 400 or such.

The other reason is that my expectation is to use alm to build a live demo of our controls lib, so other devs can try out our styles and controls coding, etc. but I want to make sure they see only what I want them to see, then edit everything on browser, build that also on browser and finally display that in another panel on the right. Very similar to plnkr, but I cannot use plnkr as the project is still very private. So, being able to manipulate the tree is a need.