Replies: 1 comment 4 replies
-
In principle, I quite like the last form -- a list file paths to export with the flexibility to supply more for some exceptional cases. However, I'm thinking about a potential conflict with For example, in the case of persetter-preset-rollup: presetter/packages/preset-rollup/source/index.ts Lines 53 to 63 in 70ac386
Then, if the {
templates: [
resolve(__dirname, '..', 'templates'),
['.babelrc.json', '.eslintrc.json', {path: "gitignore", noSymlinks: true}, '.jestrc.json', '.npmignore', '.prettierrc.json', 'tsconfig.json', 'tsconfig.build.json']
]
} and continue to accept the classic form for advanced use cases? {
templates: {
'.babelrc.json': {...}
}
} |
Beta Was this translation helpful? Give feedback.
-
Let's consider this structure inside a preset:
The invocation of resolve is repeated. I am wondering why the framework can't do it for us, if at least we made the templates directory available with a separate
templates
entry. That way it could look like this:That's less typing, but another phenomenon presents itself: this mapping could be automated using a convention over configuration pattern:
The rule would be: remove the initial underscore, and look for the templates under
templatesPath
. Use the extension (yaml
, '.json', etc) to determine what merge rule to use. For scripts we always look forscripts.*
under templates so we can leave this out.To still allow complete control we could allow exceptions:
I suspect that 'noSymlinks' could also be part of this structure, and the
template
entry could become optional, so we could do:Using convention over configuration here would encourage a consistent naming pattern for templates, which is I think desirable in a preset. And it's simply less typing and less to think about.
There are questions to resolve concerning
supplementaryConfigs
and the like.Beta Was this translation helpful? Give feedback.
All reactions