use the design repo's automated tests

[Fishrock123]

https://github.com/nucleus-js/design

probably requires adding this repo as a submodule over there?

Or maybe the other way around would be better?

[creationix]

yes, add this as a submodule next to seaduk

[Fishrock123]

@creationix I wonder if it wouldn't be more effective to submodule the tests here rather than the other way around?

[creationix]

I don't have strong opinions if you want to do it that way.

[creationix]

We could even do both. The implementations can be submodules of the design repo, but a separate test repo can be embedded in each implementation. That way we get the centralized discovery as well as fine-grained versioning for the test suite for each implementation.

[Fishrock123]

@creationix That doesn't cause some circular dependency implosion? Still not really familiar with submodules lol. :S

[creationix]

Submodules are like symlinks. The actual implementation is a just directory entry with type "commit" that contains the commit hash in the target repo. The .gitmodules file at the root of the repo gives the missing information about where to find said hash.

I meant split design into design and tests so that there is no circular dependency going on. But if you want to keep the tests inside design, then there is no technical problem having the circular references.

But, it would be a problem if someone tries to do a recursive clone, hmm...

[Fishrock123]

My original idea was tests and design but I thought it may be important to keep tests in the same repo as the text spec.

I still think we should remove the submodules from the design repo -- what purpose do they have there?

[creationix]

The purpose of the design repo pointing to implementations is for discovery. We could instead just link to them in the README instead of use a submodule if you prefer to avoid recursive submodules.