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

Initial approach #1

Closed
jonaskello opened this Issue Oct 25, 2016 · 16 comments

Comments

Projects
None yet
2 participants
@jonaskello
Collaborator

jonaskello commented Oct 25, 2016

Just to kick things of, the inital approach could be to read the yarn lock-file and generate SystemJS config.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Oct 25, 2016

Yeah, agreed. However I'm unsure of how to construct a dependency tree from the lock file. I need to work out how yarn handles dependency clashes. As in who wins (gets put in top level). I have a feeling we could leverage yarn internals to get a tree.

@jonaskello

This comment has been minimized.

Collaborator

jonaskello commented Oct 25, 2016

This issue and this issue at the yarn repo provides some more background for this project/issue.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Oct 25, 2016

Alternatively, we could simply walk node_modules and build it like that

@jonaskello

This comment has been minimized.

Collaborator

jonaskello commented Oct 25, 2016

Hmm.. Thinking about it that way, walking node_modules would make it work with npm too? Interesting that there is no existing tool that already does that :-). Or maybe there is?

As you mentioned earlier, to determine the feasibility of this approach I think one thing we need to find out is exactly what transforms jspm applies on packages as it installs them.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Oct 25, 2016

@jonaskello Yeah I was wondering about this as well. I haven't come across one. Most that I have seen take the opposite approach. Try resolve a file, fail, try another etc.

This would mean it would work for npm. But not reproducibly. Unless shrink-wrap was applied.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Oct 25, 2016

Agreed, it would be a pain if we worked on this and end up recreating JSPM. @guybedford is there any reason the approach we are following here won't work, that you can see?

@jonaskello

This comment has been minimized.

Collaborator

jonaskello commented Oct 25, 2016

Generating from the lock-file would be better for reproducibility and also if we want to automate the generation of the config, a good place would probably be to run each time the lock-file is updated. Maybe yarn provides a hook for that already or it could be added.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Oct 25, 2016

@jonaskello As far as I can see, generating from lock file would be the same as generating from walking node_modules. Should give us the same result if the install was handled by yarn. Im hoping theres a way to avoid building a tree (not that it's hard), but I want to minimize duplicated work here.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Oct 25, 2016

I don't have time to look at this this week, I have course work that needs to be submitted, and some missed due dates. But will be able to sit down and invest some time into this towards the end of next week hopefully. @jonaskello if you want to run with getting this started that would be amazing however!

@jonaskello

This comment has been minimized.

Collaborator

jonaskello commented Oct 25, 2016

I might try a naive implementation if I can find some time.

@jonaskello

This comment has been minimized.

Collaborator

jonaskello commented Oct 25, 2016

So, when getting started I just assumed the yarn.lock file was in yaml format. But at a closer look it seems it is not. Not sure what format it is. The yarn source has its own parser for it. If it is not a standard format I guess we need to use that parser.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Oct 25, 2016

Oh damn. Yeah, maybe add yarn as a dep and use that. Perhaps more can be used from the yarn project then just the parser?

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Nov 11, 2016

@jonaskello I've started the following project https://github.com/alexisvincent/systemjs-config-builder as a more general case of this project. The approach will be to trace node_modules instead of working from the yarn lock file. So we can test things out there and when we have a stable system we can pull that in as a dependency and hack on the yarn integration here.

I've also found someone else who is interested in helping with this. He built a similar thing but closely tied the build process.

If you want I'll add you as a collaborator on the other project. Let me know if you still have time to help with this.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Nov 15, 2016

I found a way to do this beautifully :D Will let you know once I've cleaned it up a bit

@jonaskello

This comment has been minimized.

Collaborator

jonaskello commented Nov 15, 2016

Interesting! :-).

Unfortunately I do not have as much time as I wish to spend on it. OTOH I really would like to see it move forward so if you need help with something specific then ping me and I will try to contribute what I can.

@alexisvincent

This comment has been minimized.

Owner

alexisvincent commented Nov 15, 2016

I should be ok 👍 Thanks for the interest though. Good news, given this package.json I can now generate this SystemJS config

Not perfect yet. But a good start :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment