Allow more options for meta config format/name
See original GitHub issueThat is, to allow not just .meta as a config file, but also .meta.json, .meta.yaml, meta property in package.json, etc.
Issue Analytics
- State:
- Created 4 years ago
- Comments:15 (6 by maintainers)
Top Results From Across the Web
Project Configuration File Format - Gerrit Code Review
The refs/meta/config namespace The namespace contains three different files that play different roles in the permission model. With read permission to that ...
Read more >Configuration - Jupytext documentation - Read the Docs
Jupytext accepts a few additional options. These options should be added to the "jupytext" section in the metadata — use either the metadata...
Read more >HTML Options - Quarto
Use the name of any system font. See ConTeXt Fonts for more information. monofont. For HTML output, sets the CSS font-family property on...
Read more >pdrutil - Collection of utilities for perl dist repos - metacpan.org
[--config-profile=profile | -P] [--debug] [-- format =name] [--json] ... inc-prereq-version-by. Increase prereq version by a certain increment.
Read more >How do you enable/use refs/meta/config? - Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com. For more options, visit https:// ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

For syntax highlighting, just click the change language mode button on the bottom right:
or CMD+Shift+P and select change language mode:
There are plenty of other projects that have non-json and non-js extensions, causing them to not have highlighting. This is not a big deal. If you want highlighting for .meta files, a better idea would be to start a
metaVS Code extension. We could put some really powerful commands into it, and it would cover your highlighting.I don’t see a benefit to unifying with other tooling. You’re creating a new repo for your meta repo. You don’t have to have a package.json in your meta repo. You only would if you want to locally install plugins. And I don’t see a reason to shove all your child project repo locations into your package.json.
Shoving many things into fewer files === more merge conflicts. Separate, and simple is better.
FYI: You can also set file associations in vscode, eg: