[mshima]

Summary

renderTemplate and renderTemplateAsync render the templates with the generator as their context (transformOptions.context: this), so a template can read anything from the generator. EJS keeps the context with the compiled template, so with the EJS cache a template rendered by several generators has an unpredictable context.

Add the templateContext feature, for renderTemplate, renderTemplateAsync, renderTemplates and renderTemplatesAsync:

templateContext	context of the templates
'generator' (default)	the generator, without a warning, as before
'warn'	the generator, warning once by template and property read from this, through the generator log
'throw'	a context where reading a property of this throws, naming the template (Template <template path> reads this.<property>: the generator is not the context of its templates, pass it in the template data). The default of the next major.
'none'	no context is passed: EJS gives the template its default this

• Reading a symbol gives undefined with 'throw', and does not warn with 'warn'.
• With 'warn', a method read from this keeps the generator as this (its private fields), and getters run on the generator.
• A context passed in transformOptions is still used.
• The default template data (_templateData(), from the config) is unchanged.
• Templates rendered with this.fs.copyTpl directly are not affected.

Behavior change

None by default: 'generator' keeps the generator as the context, without a warning.

Test plan

• eslint, prettier, build
• vitest, rendering real templates: the default and 'generator' without a warning, 'warn' warning once by template and property, a method of the generator called from a template, 'none' without a context, the data with 'throw' (renderTemplate, renderTemplateAsync, renderTemplates), the error naming the template and the property (sync and async), an explicit context

🤖 Generated with Claude Code