-
Notifications
You must be signed in to change notification settings - Fork 7
Excluding modules #8
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
Comments
@mosho1 Thanks for pushing this forward. Thats a good bet. Essentially all of these will be functions on the tree. My initial thought for this was, let people specify entry points, and since we have a working SystemJS config, we can use the Another broad stroke would be to filter out devDependencies as you suggested. Either way I feel that all of these should be exposed. Thought: It might even be worth adopting the SystemJS builder trace API, instead of the tree we have, then we can take advantage of the trace functions. This means we could extend the trace API, instead of our own system. |
I think the problem with using the trace API is that people would have to write the import statement before installing, that feels a little off. The packages to "trace" should be in a configuration somewhere (like package.json). |
@mosho1 I don't think I was clear enough. I mean to adopt the trace API Agreed though, entries and such things should either be specified as cmdline args, or in package.json. Maybe under |
That was exactly what I thought ( You said:
What if someone installs a package but doesn't use it (yet)? The way I understand it, it means he would have to run the configuration command after including it either as an entry point or import it in the tree of an existing entry point. |
Ah right. Maybe the default should be to generate for everything. But provide the option to generate an 'optimised' config, with all of these things |
Optimised is only bad for Dev experience |
I realized a flaw in my thinking. The internal tree representation is actually a library dependency tree, not a module dep tree. So using the trace api is not going to work here |
Right, though you could cross reference them. |
True |
I saw there's an item on the checklist in the readme about this. How about (optionally?) excluding all devDependencies?
The text was updated successfully, but these errors were encountered: