Template as a zip

[lizell]

Added support for the template to point to a local zip file (ending in .zip) of a template repository. This is useful if the template is on a private repo or not on GitHub.

As a bonus init now respects the general directory option. Before this change giving the directory option affected where roc was looking for configuration files and stuff, but created the project in the current working directory. Now the project is created at the given directory. If the option is not used it should work as before.

[dlmr]

I guess that process.cwd() should be changed to directory since we now get it from the command object?

I assume we are using indexOf here to check if this is a absolutePath so we can create the directory outside the current scope if we want. Maybe we should rewrite this to use the getAbsolutePath utility function that we have https://github.com/rocjs/roc/blob/master/src/helpers/index.js#L13 that would both make the code more robust and easier to parse.

[lizell]

That's is why I had the directory passed along to askForDirectory first. I removed and figured why did I ever want this here! ;) Thx. I'll fix that and also use getAbsolutePath!

[dlmr]

I think it would be better to change the signature for checkFolder to (force, directoryName, directory) and use directory as the second argument to getAbsolutePath. That means that https://github.com/rocjs/roc/pull/109/files#diff-03189079b1b3d77ef73e9e3fdb324d6dR47 would be similar to before.

What do you think?

[lizell]

I like it, but I don't think it will work. In order to keep the behavior in my added test cases I would have to

getAbsolutePath(directoryName || directory || process.cwd())

as neither directoryName or directory are mandatory (getAbsolutePath returns undefined if the filepath is not defined.)

This is the way I think it should work:

#	directoryName	directory	directoryPath
1	undefined	undefined	/cwd
2	name	undefined	/cwd/name
3	/name	undefined	/name
4	undefined	directory	/cwd/directory
5	undefined	/directory	/directory
6	name	directory	/cwd/directory/name
7	name	/directory	/directory/name

6 and 7 will not work, so to support that we could do something like:

getAbsolutePath(path.join(directory, directoryName));

Do you think it would work?

[dlmr]

Good point!

I think the right thing here might be to update getAbsolutePath so that it does not return undefined when filepath is undefined but instead either process.cwd() or the directory that was provided to it. Seems like this is the expected result in the code but I will need to look a little closer to be 100% sure if we decide to go down this path.

When running init the directory will always be absolute when running in Roc. This means the cases 4 and 6 will never happen in the table above. Or rather the path will already be /cwd/directory when processing init from the cli. This means that some tests can be updated to reflect this.

I did these changes locally and the tests seems pass correctly, or all but one. roc commands init should choose name over directory does fail but I believe that it tests an incorrect/unexpected behaviour. For me the expected behaviour is the following:

roc new name --directory directory // Should try init inside /cwd/directory/name 

---

The most important change this would bring is that all mentions of process.cwd() in the Roc commands functions should be replaced with the new directory value that by default will be process.cwd() but can be configured by the user.

[lizell]

Yepp I had updated my test, but didn't push it, since I wanted your view on things. About case 4 and 6, isn't your example case 6 exactly?

Maybe I should push the latest code including the getAbsolutePath(path.join(directory, directoryName)); and we do the process.cwd() replacing in a separate branch?

[dlmr]

Sounds good, let's do that! 👍

[lizell]

It is pushed. Should I create an issue for the refactoring of getAbsolutePath or are you already on it?

[dlmr]

I'm kinda on it in my next branch where I make the needed changes for bringing us to a stable 1.0. And I think we will need to wait with this change for that since I now have looked more closely into this and there is extensions that expects to get undefined in some places. But feel free to create a issue to make sure this is tracked correctly!

I will go ahead and merge this if the build passes! 👍

[dlmr]

I have tested this out now and it works awesomely! 👍

I'm almost ready to merge.

Just the two questions above and for some reason it seems that the tests are outputting things to the console that was not present before in regards to the init tests. Could you take a quick look at it and see if it is something that can be easily addressed?

[lizell]

Ooops, I missed to wrap my added tests in the consoleMockWrapper. I will fix that!