Is there a way to disable this rule for a specific import we want to keep at the top of the file?

[pvinis]

No description provided.

[Gelio]

Sorry for the lack of activity, I did not see the issue

You can either mention that import as a new import group in the rule configuration, or use the tslint:disable-next-line comment 🙂 https://palantir.github.io/tslint/usage/rule-flags/

If you have problems disabling the rule, please provide a concrete example so I can help

[pvinis]

I had something not working, I'll send an example soon.

[Gelio]

@pvinis Did you manage to come up with an example?

[pvinis]

Ah sorry for the delay. Here it is:

We import app/chat/helpers/sdk in a few files. The imports look like this:

• import 'app/chat/helpers/sdk'
• import { CallType } from 'app/chat/helpers/sdk'

In the file where we import the file directly, we want it to be the first import because it's importing some shims. In the second import where we have the CallType, we want it to be a regular import.

It would be nice to be able to import like import 'app/chat/helpers/sdk' // tslint:disable-line:import-order or something like that, and that would leave the import on top, with an empty line below it, and not move it around.

Right now, as a weird workaround, I have that specific file as a separate group and always first, so even in files that import the CallType, that import is the first group in the file.

Does that help/make sense?

[Gelio]

Unfortunately, there is no option to do that at the moment.

However, it seems that you want the shims to be imported first, so the rule's configuration should mention that shims should appear in the first import group.

Then, it's just a matter of differentiating the path to the module that contains the shims, e.g. have app/chat/helpers/sdk/shims for the shims and app/chat/helpers/sdk for the rest. Then, in the rule's configuration, you would that you want the shims module to be always first.

This seems to reflect reality and does not require any hacks with disabling tslint 🙂

[iamgollum]

@Gelio thanks for the clarification. Performing matching on the left side operand would be neat but the right side differentiation is workable with the right naming conventions and/or file structure as you elaborated upon. In my case, I only need the "dotenv" to be loaded at the top so I did an exact match against the string. If I have the time, I will try and contribute to the project. Thank you for an awesome npm module - my team loves it.