Merge into core

[aleclarson]

I think this plugin belongs in Meta core.

/cc @mateodelnorte

[mateodelnorte]

Agreed, however, I'd like to see a redesign before doing so mateodelnorte/meta#49

[dorner]

coming up! :)

[aleclarson]

I was thinking about merging this library with get-meta-file and merging that into https://github.com/mateodelnorte/meta. Thoughts @mateodelnorte?

[mateodelnorte]

I lean toward keeping them small, simple, and separate. The smaller a module is, the easier it is to update. And the pattern of having a new module introduce new functionality to the .meta file could be repeated easily by copying the module and modifying it to do something different.

What are the arguments for merging?

[aleclarson]

The main benefit is to simplify writing plugins. Instead of needing to learn of, install, and update the get-meta-file and meta-configure packages, I only need to import the meta package like so:

const { resolveConfig, editConfig } = require('meta');

const configPath = resolveConfig(process.cwd(), { assertExists: true });
assert(!configPath || path.basename(configPath) === '.meta');

editConfig(configPath, (config) => {
  config.projects.pop();
});

It's good to consolidate here, because reading/writing Meta configuration will be a common task for plugins.

[aleclarson]

I should clarify: I still think meta-configure should be the package that provides meta get, meta set, etc.

[aleclarson]

Hmm, I think I just want get-meta-file to be re-exported by meta. Nothing more. :)

[mateodelnorte]

Any time you work on meta, you should be meta git cloneing the entire set of repos (in addition to any new repo you're adding). So, you should automagically get all the other repos. The way plugins get their functionality included in meta, by default, is just to include them as dependencies in meta.

[aleclarson]

Are you saying that any plugin developer must/should fork the meta package and develop their plugin in said fork (alongside the core plugins)? I don't see anything wrong with that, but it wouldn't be my first approach when developing a plugin.

[mateodelnorte]

Nope. You don't need to fork. meta automatically discovers plugins according to file name conventions. So, anybody who wants to develop a plugin would either meta git clone meta itself and then npm link their plugin into meta's node_modules folder, or potentially do a global symlink so their globally installed meta can discover their new plugin.

[mateodelnorte]

You'd only fork meta if you want to create a PR suggesting that your new plugin is included in meta as a default plugin (one that automatically gets installed when you npm i -g meta).

[aleclarson]

Okay, good! But now I don't see how this relates to re-exporting get-meta-file from the meta package?

[mateodelnorte]

Here are some examples: https://github.com/mateodelnorte/meta/blob/master/package.json#L58-L61. All of these provide default functionality when you npm i -g meta.

[aleclarson]

@mateodelnorte Yeah, I'm aware of the core plugins. I wrote the new plugin-finding algo! :P

[mateodelnorte]

Heh. Don't think it does.

I think the moral of the story is that we'll update meta's dependencies to include @dorner's meta-configure plugin when it's ready!

[mateodelnorte]

Yea, I know you know. Just being explicit with all the info.

[aleclarson]

Didn't mean to derail this issue, so I'll open a new issue now. Sorry! 😅