Restrict generalization by scoping private keys

[Ayc0]

TL;DR

Add scoping mechanism for custom attributes, like:

import foo from 'bar' with { "data-foo": "bar" };
// or
import foo from 'bar' with { "custom": { "foo": "bar" } };
// or similar

Problem

Avoid another possible smoothgate in the future.

Explanation

One of the reasons for the redesign of this proposal with with {…} is to allow tools to add custom fields in them (like bundlers or runtimes for instance).

But if there is another proposal in the future to add another field (like with { type, priority }), this could face the same risks as when we want to add methods in prototypes: aka clashing with potential custom keys already added by frameworks (like what happened for .flat vs .flatten).

What about introducing in the spec the fact that, just like in HTML, certain fields (for instance in data-*) will never be used by the spec. This would allow libraries / bundlers to introduce their custom behaviors using them (if they want a data-bundlerA-priority, they'll without any risk of conflicts). And will also allow the TC39 to introduce new keys in the spec later without potential conflicts.

The name data-* is just an idea, but it could be any other form of scoping mechanism, like: with { custom: {…} } etc.

[Josh-Cena]

My suggestion is to use naming conventions—for example, prefixes like webpack-*, typescript-*, etc. The language would likely never use a name that's not an identifier, so this would certainly be same. This looks better than requiring all 3rd party attributes to live under the same object, since there aren't many first-party attributes anyways. custom: {...} would also require parsing object attribute values, while currently only string attributes are allowed.

[Ayc0]

I agree, but if we want to enforce naming conventions, it should be stated in the spec. Enforcing that all variables used by the spec would use pascalCase and that 3rd party ones need to be prefixed by a <key>- (enforcing the - in the key) would work indeed