Modules: js_set inline JavaScript expressions.

[xeioex]

Added support for inline JavaScript expressions in the js_set directive. Previously, js_set only accepted function references:

js_set $var main.handler;

Now it also accepts inline expressions:

js_set $var '(r.uri)';
js_set $var 'r.headersIn["Host"] || "none"';

Additionally, nginx-style $variable references are expanded to the corresponding JavaScript variable access. For example:

js_set $var '$uri.toUpperCase()';

is equivalent to:

js_set $var 'r.variables.uri.toUpperCase()';

In stream context, $var expands to s.variables.var.

The expansion is a textual substitution at configuration parse time for $name patterns where name starts with [A-Za-z_].

Comparison of Approaches

1. $var Shorthand vs No Shorthand

	$var shorthand	No shorthand
Syntax	'$uri.toUpperCase()'	'r.uri.toUpperCase()'
Expands to	r.variables.uri.toUpperCase()	used as-is
nginx-idiomatic	Yes — familiar $var references	No — pure JS, foreign to nginx users
Access scope	r.variables.* only	Full request object (r.uri, r.headersIn, r.args, etc.)
Ambiguity	$uri means r.variables.uri, not r.uri	None — what you write is what runs
Conflicts	Clashes with JS ${...} template syntax	No conflicts
Learning curve	Looks simple but hides the r.variables.* mapping	Requires knowing the JS r API
Portability to files	Breaks when moved to js_import — $uri is not valid JS	Works identically in inline and js_import files
Pros	Familiar to nginx users, shorter for common variable lookups	No ambiguity, full API access, what you write is what executes, seamless migration from inline to file
Cons	Only reaches r.variables.*; $ ambiguity with JS syntax; textual substitution may surprise users; inline expressions tend to grow — when moved to a js_import file the shorthand stops working, forcing a rewrite	More verbose for simple variable access (r.variables.uri vs $uri)

---

2. Expression Syntax (current) vs Template Literals

	Expression	Template Literal
Syntax	js_set $v 'expr';	js_set $v '`...${expr}...`';
Wrapper	return (expr)	return (`...`)
String building	'$uri + "_" + $host'	'`${r.uri}_${r.host}`'
Readability	Operators and concatenation visible	Natural interpolation, reads like a string
nginx.conf parse	Works	Works (backticks are literal in '...')
$var shorthand	Compatible	Conflicts — $ is claimed by ${...}
Arbitrary JS	Single expression	Arbitrary expressions inside ${...}
Inline code concern	Moderate — clearly an expression	Higher — template strings can hide complex logic in ${...} blocks
New syntax to learn	None — standard JS expression	Backtick-inside-single-quote nesting
Pros	No new syntax layer, $var shorthand works, clear boundary (one expression), nginx users don't need to learn template literal semantics	Natural string interpolation, cleaner when building strings with embedded values
Cons	String concatenation with + is verbose, quoting gets awkward for strings within expressions (r.headersIn["Foo"] || "none")	Incompatible with $var shorthand, backtick-inside-single-quote nesting is unusual, blurs the line between config and inline code, marginal benefit over expression syntax

Please, share your thoughts on different approaches.

[drsm]

Hi!

Maybe add an r.vars.uri shorthand instead of substitution?

[VadimZhestikov]

My main concern is the $var shorthand implemented as textual substitution at config-parse time. Since this is not js-aware, it can rewrite $name inside js string literals or other contexts where the user may expect literal text, which makes the feature surprising and harder to document.

Lets avoid this rewriting

[xeioex]

My main concern is the $var shorthand implemented as textual substitution at config-parse time. Since this is not js-aware, it can rewrite $name inside js string literals or other contexts where the user may expect literal text, which makes the feature surprising and harder to document.

Lets avoid this rewriting

Agree, and I removed the config time rewriting for the same reasons. Instead, r.vars.xxx is introduced, which will work in inline and not inlined code. Will update the patch when ready.