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:
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:
// 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} />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)
@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.
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 suc
@marinho Perhaps you might not know of these features:
- The files that are in the compilation context are colored green. Everything else is pseudo noise as far as TypeScript is concerned.
- There is also project filepath search which only filters the same files (files in the compilation context).
That should reduce some of the noise
https://github.com/driftyco/ionic-site/pull/780#event-796252124
cheers, i love your project.