Feedback for v3

[faassen]

A few more questions concerning v3 of presetter. My goal is to be able to write a preset that's as straightforward as possible.

• I am trying to figure out how peerDependencies and devDependencies work in a preset. Which become dependencies of the project that uses the preset? Why don't presets have simple dependencies?

• the setup logic in some of the presets is quite complex and seems to be doing functionality that could be done by the presetter system itself. There are a lot of lines like this js-yaml templates/eslintrc.yaml | pupa --test=spec --output=lib > .eslintrc.json which duplicate behavior of presetter itself to a certain extent.

• I still see types defined like Variable and PresetAsset defined in the presets. These could be imported from presetter itself to make the preset a lot more readable, and I don't understand why that isn't happening.

• You define a PresetConfig type and export it, but I'm struggling to find what this type is being used for. If I look through the source code I can't see it being referred to anywhere, so what purpose does it serve?

• You showed me an example of a nested config file like .github/workflows or husky files, but I can't find it anymore. :)

[alvis]

• I am trying to figure out how peerDependencies and devDependencies work in a preset. Which become dependencies of the project that uses the preset? Why don't presets have simple dependencies?

peerDependencies so that it's consistent with how npm work. The reason why it's not independencies because it will have a chance that the dependencies will be installed under the preset folder (e.g. node_modules/your_preset/node_modules/package) if it's not dedupled

• the setup logic in some of the presets is quite complex and seems to be doing functionality that could be done by the presetter system itself. There are a lot of lines like this js-yaml templates/eslintrc.yaml | pupa --test=spec --output=lib > .eslintrc.json which duplicate behavior of presetter itself to a certain extent.

Yes. It's only for presetter-preset-essentials & presetter-preset-strict. They use this method because they also use the content provided by the preset package themselves too. But as a dependency of presetter, they cannot use presetter to bootstrap the content. It's a solution to the chicken and egg problem.

• I still see types defined like Variable and PresetAsset defined in the presets. These could be imported from presetter itself to make the preset a lot more readable, and I don't understand why that isn't happening.

Yes, you can. The only exceptions are presetter-preset-essentials & presetter-preset-strict. Same reason, as a dependency of presetter, they can't import things from their child. Other presets can import PresetAsset directly from presetter. See
https://github.com/alvis/presetter/blob/master/packages/preset-react/source/index.ts

• You define a PresetConfig type and export it, but I'm struggling to find what this type is being used for. If I look through the source code I can't see it being referred to anywhere, so what purpose does it serve?

Only for documentation purposes to indicate which fields will be considered by the preset.

• You showed me an example of a nested config file like .github/workflows or husky files, but I can't find it anymore. :)

Check out presetter-preset-strict for husky. Haven't got time to make a .github/workflows preset yet. But there will be one soon.

[faassen]

Thanks again for your answers!

peerDependencies so that it's consistent with how npm work. The reason why it's not independencies because it will have a chance that
the dependencies will be installed under the preset folder (e.g. node_modules/your_preset/node_modules/package) if it's not dedupled

Ah, to avoid it being completely inaccessible as an implementation detail of the package, while it really needs to be in the node_modules of the package that uses the preset. I think I get it.

I realize I got confused by looking at preset-preset-essentials as examples. I am interested in creating a preset from first principles without building on existing presets, as that would keep things as flat as possible and allow a complete maintenance of choices.

Concerning why presetter-preset-essentials and -strict use this method, I hadn't realized I couldn't study all presets as an example of presets - perhaps we should make obvious what are good example presets and which ones aren't. I'm interested in creating an independent base preset myself. Am I correct in that it wouldn't have this problem as it's not a dependency of presetter?

But what if I want to use this preset in itself? A preset that contains a typescript configuration and uses typescript, for example. How would I do this without this js-yaml approach?

I am wondering whether templates for use cases of this couldn't actually be taken from the files they install. That is, instead of having the templates be stored in a separate templates subdirectory, let the files themselves be the templates. That way there's no need to install them. The one thing where this would break is for variable interpolation, but we could forbid that (by erroring out, perhaps) if you do that.

If you want to actually document PresetConfig in a programmatic way I do still recommend using a zod schema. This can actually validate a JS object (like JSON) and presetter could actually validate whether the configuration is allowed.

[faassen]

What I'm wondering is whether for templates without variables, we could make it easy to store the template in its destination location.

That way it can serve as both a template and as the configuration for the code in the presetter repository itself. So I don't need to copy a tsconfig in order to use it with js-yaml, but I simply keep it in its original location.

[alvis]

Wish granted! 🪄 You don't need to use variables in a template at all. js-yaml is just a tool for me to convert my template in yaml format into json files. In fact, you can have your templates in json format then you don't need to use js-yaml or something similar at all.

[faassen]

What I'm asking for is this:

The ability to write a preset where the templates (that don't need variables) are already in their target location. That way my tsconfig.json doesn't need to be copied, it's just in the place I would expect, serving both a tsconfig.json for any TS code in this project, and as a template when I use the preset.

[faassen]

I wonder whether this would just work, I will try it out. :)

[alvis]

Yes. It'd just work. In the current format, let's say you want to export your tsconfig.json, you can have this in the default export of your preset:

{
  template: {
    // ... other templates
    'tsconfig.json': resolve(__dirname, '..', 'tsconfig.json') // <- it will use your tsconfig.json at the project root of your preset as a template
  }
}