Use entry file as an alternative to egg.json

[maximousblk]

Is your feature request related to a problem? If so, please describe.

the problem is another package.json in the form of egg.json

Describe the solution you'd like

Use deps.ts as an alternative to egg.json?

like just export an object named egg which eggs could import and work with.

example:

// ./mod.ts

export const egg = {
  name: "audit",
  version: "1.0.0",
  description: "Add a notification for insecure versions of your modules.",
  stable: true,
  unlisted: false,
  repository: "https://github.com/maximousblk/audit",
  files: ["./mod.ts", "./README.md"],
};

this would also be good in case someone needs this metadata in their application or metadata of their dependencies.
And this can also be used in auditing as this information is contained inside the package.

Describe alternatives you've considered

none

Additional context

possible solution to nestdotland/eggs#3

[t8]

This is actually a creative idea that we hadn't yet considered. Because users' packages are already configured with the concept of egg.json, we could make this an alternative solution that would eliminate the need for a separate file. I'll be curious to see what @justablob and @zorbyte think.

[zorbyte]

This is dependent on a de facto standard and would thus be restricting to users who do not subscribe to such methodologies. I'm -1 for this.

[zorbyte]

If we allowed it as strictly an alternative and not the standard, that wouldn't be that bad I guess, but adding too many means to configure something will clutter the CLI not in terms of SLOC but rather in features.

[maximousblk]

so what about in the module's entry file, we export an egg object and use that in the cli?

// mod.ts (or ANY other JS/TS file)

export * from "./denon.ts";
export * from "./src/watcher.ts";
export * from "./src/runner.ts";

export { DenonConfig, DEFAULT_DENON_CONFIG } from "./src/config.ts";

export const egg = {
  "name": "denon",
  "description": "Monitor any changes in you Deno application and automatically restart.",
  "entry": "./mod.ts", // won't need after this
  "stable": true,
  "version": "2.2.0", 
  "unlisted": false,
  "files": [
    "./README.md",
    "./deps.ts",
    "./test_deps.ts",
    "./denon.ts",
    "./denon.config.ts",
    "./mod.ts",
    "./templates/**/*",
    "./src/**/*"
  ]
}

then in the CLI:

eggs publish mod.ts --bump="2.2.1" --stable="true" --unlisted="false"

or if you don't wanna change anything from the config, you would do:

eggs publish mod.ts --bump="2.2.1"

[martonlederer]

Okay so I really like this idea. It is really convenient and easy. Should be understandable for everyone. We could even offer type checking for it, since we already have the config interface defined

[littledivy]

I like the idea of keeping a dynamic config but keeping it in just any js or ts file will be an extra step for user to specify in the publish command.

What I think is that we allow users to place their eggs config in any file but we also have a default file from where the config is exported called eggs.config.ts

[t8]

@divy-work I think that only searching for an exported config in the entry file won't be any extra work for the user because they have to have an entry file anyway. I agree that we don't necessarily have to search through all files being uploaded or in a given directory.

Also, what would the point of having egg.config.ts be if we already offer egg.json and egg.yml options? Would this just be another optional configuration format?

[littledivy]

I agree but isn't mod.ts also another config too? The only difference is that it is part of the project whereas egg.config.ts is not.

We can look at various projects that could have exported the config from an entry file but they mandated a separate one (for example: webpack.config.js)

Using entry file will not only force the user to put their config in source control but also go against the idea of decentralization.

[bytedeveloperr]

+1