fix: prevent removing imports if a rangeEnd is passed

[MattLish]

This prevents destructive operations when a rangeEnd is passed.

Prior to this, if rangeEnd was passed, the imports would be removed because the plugin considered them unused.

This should solve a bug experienced in JetBrains IDEs https://youtrack.jetbrains.com/issue/WEB-50178/Code-reformat-with-prettier-and-prettier-plugin-organize-imports-deletes-imports-if-Optimize-imports-is-enabled

Closes #110

[alexander-doroshko]

It might also make sense to check for rangeStart being 0.

[MattLish]

It might also make sense to check for rangeStart being 0.

From what I could tell, rangeStart seemed to have no impact on the imports at all

[simonhaenisch]

Just testing this and the following happens:

Prettier initially calls the plugin's preprocess with (omitting non-relevant fields):

{
  code: '<original-code>',
  options: {
    rangeEnd: 10, // or whatever was set
    originalText: undefined,
  }
}

Prettier calling the plugin at that point seems a bit weird but I guess maybe it's just because we're hooking into the preprocess hook.

Then it calls the plugin's preprocess a second time with

{
  code: '<just-the-code-in-the-range>',
  options: {
    rangeEnd: Infinity, // default value
    originalText: '<original-code>',
  }
}

I think the most correct (and performant) behavior is to

• not do anything if options.originalText is defined (check this first because Infinity !== code.length is always true)
• not do anything if options.rangeEnd !== code.length or options.rangeStart !== 0

wdyt?

[simonhaenisch]

An alternative would be to pass originalText instead of code to the TypeScript API, but then it's not trivial to figure out which range of the organizeImports result to pass back (since the formatted result could have a different length).

[MattLish]

@simonhaenisch Sorry for not getting back to you. That works for me, thanks for sorting the PR!