CLI + Web: Keep egg configuration away from source.

[zorbyte]

I noticed the employment of an egg.json file with the CLI. This violates the Deno philosophy of making the source code independent of a package manager. I propose we use a .eggignore file to ignore files for upload and move the configuration of the package to the website, with the option of initial configuration being present on the first publish with the CLI as well.

[t8]

I thought about this too. The only reason we chose this method was because the alternative is extremely non-user friendly. It would take a simple task and give it extra steps. Though I am aware the Deno community doesn't like the idea of another package.json, it would be way more janky to try to go around it. Besides, I don't think it is fair to see this as another package.json situation for two reasons:

1. egg.json does not handle project dependencies.
2. egg.json does not include configuration necessary to run the project. The user could easily download a given package and run deno run packageName with no issues.

That said, the source code is still completely independent and would function perfectly fine without this information. The primary purpose of egg.json is to add information to the registry for other users to see. Besides, we really aren't a package manager; we're a registry with a built-in CDN.

Finally, what would the difference be if adding configuration arguments in the CLI was an option?

[zorbyte]

First publish: interactive prompt. Further edits on web

[t8]

We won't have time to implement this immediately for 0.1.0, but I'll leave this issue opened so we can come back to this in the future.

[t8]

We have received more feedback from several people against the idea of the egg.json file we currently have implemented. This discussion is to determine the pros and cons of both.

In addition, we'd like to come to a general consensus between the authors, contributors, and package developers on this topic.

[martonlederer]

I think while .eggignore is not as user friendly, in the long run we would benefit from it greatly.

Removing the egg.json and combining the cli and the . eggignore file (which would be optional) would be the best to align with the deno philosophy

[jpwilliams]

Coming at this from a not-very-experienced-with-Deno perspective, why is a .eggignore or egg.json file needed at all?

My line of thought is that everything being exported should be defined in mod.ts, so all the files intended to be included in a nest.land "deployment" should be accessible by just parsing that.

It'd be awesome to have a sort of config-less registry that just grabs your code in its Deno style and does its thing, though I see that the essential name/description/stable metadata would have to be defined somewhere. 🤔

[martonlederer]

@jpwilliams I see your point. Maybe we could just require everyone to use something like this in their entry file/mod.ts:

export let name = 'Package name';
export let description = 'package description';

[t8]

This is another really interesting idea. I assume that some users may get angry at the fact that they have to "crowd" their module code with these variables. Although, it would be a great alternative for the people who don't mind this and want to get rid of egg.json/yml.

[martonlederer]

I agree. Maybe optionally it could be beneficial. We'd have to find a solution to mark the entry file though.
Maybe a comment on the first line?

/* @nest.land entry */