Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI: support for wildcards #916

Closed
wants to merge 1 commit into from
Closed

CLI: support for wildcards #916

wants to merge 1 commit into from

Conversation

am11
Copy link

@am11 am11 commented Oct 18, 2014

Addresses gh-911.

return;
}

var glob = require("glob");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't use NPM packages in the compiler (tsc.exe doesn't run under node); you'll need to re-implement whatever functionality this package is providing. Go through the sys interface for file system operations.

@mhegazy
Copy link
Contributor

mhegazy commented Oct 18, 2014

Thanks @am11; in addition to @RyanCavanaugh comment; we also need to detect the directories touched and watch them for the --watch scenario. For instance 'tsc --watch src*.ts' would cause us to watch directory 'src' so that adding a new file in the directory would cause us to pick it up and recompile.

@am11
Copy link
Author

am11 commented Oct 19, 2014

I thought it can consume node.js packages, as there are only two methods of installing TypeScript on the official website; npm or VisualStudio (which probably taps directly into the TS compiler code, bypassing CLI code).

Nonetheless, node-glob uses minimatch to match glob patterns and graceful-fs to solve edge cases in various filesystems. Those repos are continuously maintained. That would be too much work to port and then keep it maintained for a little outcome.

@panuhorsmalahti
Copy link

@RyanCavanaugh Why not start running tsc.exe under Node.js? It would enable the use of npm packages which is required for certain features (like globbing here).

@RyanCavanaugh
Copy link
Member

Having tsc.js runnable under at least two runtimes makes sure that we don't over-bet on one platform or another and keeps the interactions between tsc and external libraries to cases where we're sure we really need it.

For example, there are people that want to run tsc.js on Nashorn, so keeping that external surface area to a minimum makes that proposal reasonable to implement instead of an invasive re-write.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants