Skip to content

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

Open
srolel opened this issue Nov 25, 2016 · 9 comments
Open

Excluding modules #8

srolel opened this issue Nov 25, 2016 · 9 comments

Comments

@srolel
Copy link
Contributor

srolel commented Nov 25, 2016

I saw there's an item on the checklist in the readme about this. How about (optionally?) excluding all devDependencies?

@alexisvincent
Copy link
Owner

@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 systemjs-builder trace api, to determine the exact dependencies that are relied on by the entries. Then we can prune out all others.

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.

@srolel
Copy link
Contributor Author

srolel commented Nov 28, 2016

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).

@alexisvincent
Copy link
Owner

@mosho1 I don't think I was clear enough. I mean to adopt the trace API internally, instead of the custom tree representation I have. Not to expose it. Although we could expose the arithmetic part.

Agreed though, entries and such things should either be specified as cmdline args, or in package.json. Maybe under systemjs key?

@srolel
Copy link
Contributor Author

srolel commented Nov 28, 2016

That was exactly what I thought (systemjs key in pjson).

You said:

we can use the systemjs-builder trace api, to determine the exact dependencies that are relied on by the entries

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.

@alexisvincent
Copy link
Owner

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

@alexisvincent
Copy link
Owner

Optimised is only bad for Dev experience

@alexisvincent
Copy link
Owner

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

@srolel
Copy link
Contributor Author

srolel commented Dec 5, 2016

Right, though you could cross reference them.

@alexisvincent
Copy link
Owner

True

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

No branches or pull requests

2 participants