Generated code style

[levithomason]

Currently, create-index files are identified by the string:

'create index';

This string is not linter friendly since it is not an assignment nor call. As far as I know, there is no way to define new directives like 'use strict'.

What about using a comment like eslint, flow type, and others:

/* create-index */

or

/* @create-index */

The latter would give a little more certainty when parsing comments for the flag. A flag like this in general would also allow parsing options following the flag as with eslint for instance.

Thoughts?

[gajus]

It should not trigger any linting rule. It is a simple statement. Same as if you were to call a function - you are not expected to assign it to anything. Do you have a specific ESLint rule in mind?

"use strict" is not a directive on itself either. It is a regular statement just like the former. What makes it a directive is that ES engine seeks out for it. Another example is "use strong".

I don't hold strong opinion about this, but introducing a breaking change just for code style reasons is not a good way to maintain a library.

Finally, the only argument that I can think of against this approach is that code minifiers will not remove "create index" statement. But the negligible performance and size implications make this of no difference.

Thoughts?

On Mar 1, 2016, at 22:20, Levi Thomason [email protected] wrote:

Currently, create-index files are identified by the string:

'create index';
This string is not linter friendly since it is not an assignment nor call. As far as know, there is no way to define new directives like 'use strict`.

What about using a comment like eslint, flow type, and others:

/* create-index */
or

/* @create-index */
The latter would give a little more certainty when parsing comments for the flag. A flag like this would also allow parsing options following the flag as with eslint for instance.

Thoughts?

—
Reply to this email directly or view it on GitHub.

[levithomason]

Looks like the directive lint rule was a red herring actually. Though I'm realizing linter issues are further reaching than originally thought. Use of semicolons throws in our code bases for instance. We could ignore all index files, but that would exclude manually created index files from linting which is not good either.

Immediate solutions that come to mind are convoluted, but include things like config options or a template file so you could add your own /* eslint-disable */ rules or something.

Ideas on how to have some level of control over what gets generated?

[gajus]

Will think about it overnight.

On Mar 1, 2016, at 23:43, Levi Thomason [email protected] wrote:

Looks like the directive lint rule was a red herring actually. Though I'm realizing linter issues are further reaching than originally thought. Use of semicolons throws in our code bases for instance. We could ignore all index files, but that would exclude manually created index files from linting which is not good either.

Immediate solutions that come to mind are convoluted, but include things like config options or a template file so you could add your own /* eslint-disable */ rules or something.

Ideas on how to have some level of control over what gets generated?

—
Reply to this email directly or view it on GitHub.

[gajus]

@levithomason I don't think that configuring output is an option. It makes little sense to be concerned with generated code style. What about adding:

/* eslint-disable */
/* jshint ignore:start */

to the top of generated file?

[levithomason]

That would solve any potential linter issues and seems like a good iteration to me.

[gajus]

Do you still want to create a separate issue for the original issue? The identifier.

[levithomason]

I think the lint ignore captures the intent.

[gajus]

Use // @create-index to target files.