Feature: `importOrderMergeDuplicateImports` #19

fbartho · 2022-05-18T19:55:53Z

This PR implements import declaration merging for duplicate imports.

I had to adjust getCodeFromAST so that we could still provide the original nodes, even if some of the nodes were being deleted.
It leverages the existing chunking logic, so if there's a side-effect import, or a prettier-ignore import, it won't merge across that boundary.
I did not implement conversion of import type { stuff } into import { type stuff } as it was not obvious when this would be wise. If we want to control that with an additional config option, something like importOrderMergeTypeStyle: "none" | "to-normal-import" | "unmerge" I could be convinced. I forsee people wanting opposite sides of the coin for that one.

Please let me know what you think and if there's any edge-cases I missed!

Just use javascript or js

IanVS

I don't have time for a full review right now, but thanks for hopping in and working on this. I did have one question that would be good to discuss, and I'll try to give a full review soon.

README.md

blutorange · 2022-05-19T04:44:54Z

src/utils/__tests__/merge-nodes-with-matching-flavors.spec.ts

+        "
+    `);
+});
+it("doesn't merge duplicate imports if option disabled", () => {


Tests are always appreciated, it's great that you added some. But regarding snapshot tests, there's a special directory for those: https://github.com/IanVS/prettier-plugin-sort-imports/tree/main/tests that uses Jest snapshot testing. Could you move these tests there? That would keep it a bit more consistent.

Snapshots tests are integration tests that check whether the plugin as a whole works as expected. https://github.com/IanVS/prettier-plugin-sort-imports/tree/main/src/utils/__tests__ is meant for unit tests of the single functions in the source code. And while having unit tests won't hurt, personally I agree with you and consider integration tests that check how the plugin works as a whole more important for this plugin.

@blutorange I guess I'm confused as to the exact ask.

I'm definitely asserting specific functionality of the merge-nodes-with-matching-flavors, I just found it easier to validate the output by calling through the higher level API, because the output is just source-code, rather than somehow creating "artificial" arrays of nodes and shoving them into just the merge-function itself.

In this next PR: #20 I added a bunch of additional test cases to the same file -- those additional test cases came from here and those were indeed unit tests as well.

I think one cause of the organizational comments is that I'm using toMatchInlineSnapshot for developer-updating convenience, rather than toEqual as seen in the source-tests which requires the developer to update any changes by hand.

Options I see:
A. Rewrite tests to target lower level API mergeNodesWithMatchingImportFlavors directly
B. Rewrite tests to use toEqual as seen in other test cases and the source-tests
C. Rewrite tests to toMatchInlineSnapshot -> toMatchSnapshot + to move these tests to the special directory for traditional snapshots

What would you two like me to do?

I think one cause of the organizational comments is that I'm using toMatchInlineSnapshot for developer-updating convenience, rather than toEqual as seen in the source-tests which requires the developer to update any changes by hand.

Personally I'm not a big fan of snapshot tests, normally. I think it works well for the integration tests, but I'd rather have explicit .toEqual() in unit tests. They're a bit more of a pain to change, sure, but they're also harder to accidentally update just to make the tests pass without understanding the reason for the change.

So, I would vote for option B above, for anything that's not in the top level tests directory integration tests.

Okay, I'll convert all the toMatchInlineSnapshot tests to a toEqual

So basically, you are testing getCodeFromAst and you only use prettier.format(...) to clean up the code before the comparison (and you don't apply our plugin to the prettier.format(...) call). Then yeah, I was confused by that and toMatchInlineSnapshot.

I have now pushed that change of toMatchInlineSnapshot -> toEqual to both PRs #19, #20

blutorange · 2022-05-19T05:22:25Z

src/utils/merge-nodes-with-matching-flavors.ts

+    nodeToKeep.specifiers.push(...nodeToForget.specifiers);
+
+    // The line numbers will be all messed up. Is this a problem?
+    nodeToKeep.leadingComments = [


I'm wondering what exactly people would expect how comments are merged. Consider

// comment 1 // comment 2 import { foo } from "a" // comment 3 // comment 4 // comment 5 // comment 6 import { bar } from "a" // comment 7 // comment 8

which results in

// comment 1 // comment 2 // comment 3 // comment 4 // comment 5 // comment 6 import { foo, bar } from "a" // comment 7 // comment 8

If one deletes the second import manually and adds the import to the first, one would get

// comment 1 // comment 2 import { foo, bar } from "a" // comment 3 // comment 4 // comment 5 // comment 6 // comment 7 // comment 8

I can see an argument for both cases. Though I'd assume comments in the import section are rare in general and if they do occur, they are probably meant as an explanation for a particular import, so keeping comments on top sound like the right thing to do.

I see both cases too. I think this is a fundamental tradeoff of using this feature of the plugin. Unless we want to disable merging imports if there are any leading/contained/trailing comments, I think this tradeoff is acceptable, but that's just one vote?

Looking at the few-hundred-file code-base that I'm applying this too, only a few comments got shifted, and only one of them was sensitive (@ts-expect-error -- Singular exception allowing import of JS into TS even though our codebase doesn't normally allow that).

I think that the behavior shown as current (all comments go above) is the "more correct" option. If that's what the code is doing now, I say we stick with it.

I think the current behavior is reasonable, but maybe unintuitive. I think the root cause is that the parser prefers to assign comments to the leading position than the trailing position?

So comments 3, 4, 5, 6 are leading comments for the 2nd import, and my code moves them to be leading comments for the 1st import.

If comments 3-6 were considered trailing comments for the 1st import, then the behavior would have matched the manual process and maybe been a hair more intuitive?

Again, I agree the way it behaves now is probably the "more correct" option even if it doesn't match how a human would visualize the operations. Leading vs trailing comments is a weird thing to specify tbh.

/shrug it's intuitive to me, if we're combining the comments above each of the imports to remain above the combined import. I also think this is a super rare edge case, and probably not worth spending too much effort on perfecting. ;)

blutorange · 2022-05-19T05:28:50Z

src/utils/merge-nodes-with-matching-flavors.ts

+
+    nodeToKeep.specifiers.push(...nodeToForget.specifiers);
+
+    // The line numbers will be all messed up. Is this a problem?


There's the part where it removes nodes from the original code which relies on the line number being correct (it did so even before the linked commit).

It is called from

prettier-plugin-sort-imports/src/utils/get-code-from-ast.ts

Line 35 in b5c23c7

const codeWithoutImportsAndInterpreter = removeNodesFromOriginalCode(

I think that might be alright since it should operate on the original nodes, but perhaps you could check again that the nodes passed to that function are not the modified ones?

The nodes are both the modified & the original ones -- exactly line: cf4e6af#diff-ab5d98b73e57fb0fe6cb1b2b9ea7d14530182d5d1987eae7c545bd15f4528cfeR37

The trick is that the modified nodes don't have their line-numbers adjusted. The line-numbers still match what's in the provided code.

So… I think we're good?

Yes, I think so. If not, and if it did remove code at the wrong position, then the tests would have failed already

I don't quite understand this, and it relates to my comment from earlier about why we're providing both the modified and original nodes. But, feel free to ignore me, if y'all think it's fine how it is.

That comment was a bit out of date, as I've now learned that that's actually an important attribute of how getCodeFromAst functions. It needs the old line-numbers/loc to properly move things around!

// These mutations don't update the line numbers, and that's crucial for moving things around. // To get updated line-numbers you would need to re-parse the code after these changes are rendered!

IanVS

Overall I think this looks good. I had a few minor comments and questions, but I think this is pretty close to mergable. Thanks for the work on this, @fbartho.

README.md

src/constants.ts

IanVS · 2022-05-20T00:40:19Z

src/preprocessor.ts

    if (importNodes.length === 0) {
        return code;
    }

-    const allImports = getSortedNodes(importNodes, {
+    const remainingImports = getSortedNodes(importNodes, {


Question, why the change to the name here? Remaining after what? Is this because getSortedNodes will now also combine/remove some nodes?

Yes, the return value of getSortedNodes is no longer "all imports" it's just the "imports that weren't deleted"

I'll rename this inline with renames I'm doing to match your feedback on naming of parameters to getCodeFromAst

src/utils/get-code-from-ast.ts

IanVS · 2022-05-20T00:51:44Z

src/utils/get-code-from-ast.ts

-) => {
+export const getCodeFromAst = ({
+    nodes,
+    importNodes = nodes,


The naming here feels a little bit odd. It's not immediately clear what the difference should be between nodes and importNodes, since nodes is also a list of import nodes.

is importNodes a superset of nodes? Why do we need to pass both in here, since both are being spread into an array? Or could we just pass importNodes, if it contains all of nodes, plus additional ones?

Yes, importNodes is a superset, we need to pass the original nodes so that the old code-locations can be deleted when we merge a node. Once I was deleting some of the nodes from the nodes-array then the generated output code had the properly sorted & modified nodes followed by the unmodified nodes I wanted to have deleted.

How do you feel about these names?

/** * This function generates a code string from the passed nodes. * @param nodesToOutput The remaining imports which should be rendered. (Node specifiers & types may be mutated) * @param allOriginalImportNodes All import nodes that were originally relevant. (This includes nodes that need to be deleted!) * @param originalCode The original input code that was passed to this plugin. * @param directives All directive prologues from the original code (e.g. * `"use strict";`). * @param interpreter Optional interpreter directives, if present (e.g. * `#!/bin/node`). */ export const getCodeFromAst = ({ nodesToOutput, allOriginalImportNodes = nodesToOutput, originalCode, directives, interpreter, }: { nodesToOutput: Statement[]; allOriginalImportNodes?: Statement[]; originalCode: string; directives: Directive[]; interpreter?: InterpreterDirective | null; }) => {

IanVS · 2022-05-20T01:15:34Z

src/utils/__tests__/merge-nodes-with-matching-flavors.spec.ts

+    import { default as Def2 } from 'd';
+    import { default as Def1 } from 'd';
+    import Foo1 from 'e';
+    import Foo2 from 'e';


There's a ton going on here, it might make the test more readable if it were broken into separate test cases.

More granular unit tests were submitted in #20

IanVS · 2022-05-20T01:31:03Z

src/utils/merge-nodes-with-matching-flavors.ts

+        },
+        {
+            [importFlavorRegular]: [] as ImportDeclaration[],
+            [importFlavorType]: [] as ImportDeclaration[],


Typecasting works and is probably fine here, but normally I prefer to use a generic on the reduce call, like

return nodes.reduce<{[key: typeof importFlavorRegular | typeof importFlavorType]: ImportDeclaration[]}>(

That's a bit clunky in this case, but it lets us avoid using as. Go ahead and leave this as-is, though, just wanted to mention it.

Did it, but slightly differently!

src/utils/merge-nodes-with-matching-flavors.ts

IanVS · 2022-05-20T01:44:32Z

src/utils/merge-nodes-with-matching-flavors.ts

+
+    nodeToKeep.specifiers.push(...nodeToForget.specifiers);
+
+    // The line numbers will be all messed up. Is this a problem?


I don't quite understand this, and it relates to my comment from earlier about why we're providing both the modified and original nodes. But, feel free to ignore me, if y'all think it's fine how it is.

Try to improve the naming and docs for the parameters, particularly the nodes vs importNodes distinciton

…re stale!

fbartho · 2022-05-20T04:37:49Z

@IanVS PR Feedback applied to this and #20 -- happy to do another round when you get another chance to look.

IanVS · 2022-05-25T15:01:20Z

I will give this a final review soon. I have been on a work event for a few days, and have some other things to catch up on, but will try to get to it this week.

IanVS

Great work here, I pushed a small commit to add a couple of tests to convince myself everything's working correctly, and a few small comments to remind myself what is going on when I look at this again in the future.

fbartho added 5 commits May 18, 2022 12:26

Add TypeScript enforcement to not-forgetting our Options schema!

d4df2f0

Change syntax of getCodeFromAst to allow for node deletion

cf4e6af

Github-linguist doesn't understand ecmascript 6

f03f96b

Just use javascript or js

Feature: importOrderMergeDuplicateImports - Fixes #4

6c47166

Merge branch 'main' into fb/simplify-import-duplicates

dc43318

fbartho requested review from blutorange and IanVS May 18, 2022 19:55

fbartho changed the title ~~Feature: importOrderMergeDuplicateImports - Fixes #4~~ Feature: importOrderMergeDuplicateImports May 18, 2022

fbartho mentioned this pull request May 18, 2022

[Feature] Combine type and value imports #4

Closed

IanVS reviewed May 18, 2022

View reviewed changes

README.md Show resolved Hide resolved

blutorange reviewed May 19, 2022

View reviewed changes

switch from toMatchInlineSnapshot to toEqual

9ef2abe

This was referenced May 19, 2022

Feature: group type-imports when sorting Identifiers #25

Closed

New major version -- what do we want to change #22

Closed

IanVS reviewed May 20, 2022

View reviewed changes

fbartho added 8 commits May 19, 2022 20:49

PR Feedback: rename regular imports to value imports

f5f9e26

PR Feedback: Readme wording

42999c9

PR Feedback: rename getCodeFromAst parameters

2fe3128

Try to improve the naming and docs for the parameters, particularly the nodes vs importNodes distinciton

PR Feedback: import-flavor @returns documentation

e393e5e

PR Feedback: hoist hasIgnoreNextNode for reuse

e569488

PR Feedback: Add strong types for ChunkType/FlavorType

0e3a871

PR Feedback: deleteContext -> nodesToDelete

d0a2692

PR Feedback: comment-update: once you mutate nodes, lines/locations a…

6cb7764

…re stale!

fbartho requested review from blutorange and IanVS May 20, 2022 04:38

Add a few tests and comments

54ec637

IanVS approved these changes Jun 9, 2022

View reviewed changes

IanVS merged commit 3233783 into main Jun 9, 2022

IanVS deleted the fb/simplify-import-duplicates branch June 9, 2022 20:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature: `importOrderMergeDuplicateImports` #19

Feature: `importOrderMergeDuplicateImports` #19

fbartho commented May 18, 2022

IanVS left a comment

blutorange May 19, 2022

blutorange May 19, 2022

fbartho May 19, 2022

IanVS May 19, 2022

fbartho May 19, 2022

blutorange May 19, 2022 •

edited

Loading

fbartho May 19, 2022

blutorange May 19, 2022

fbartho May 19, 2022

IanVS May 19, 2022

fbartho May 19, 2022

IanVS May 19, 2022

blutorange May 19, 2022

fbartho May 19, 2022 •

edited

Loading

blutorange May 19, 2022

IanVS May 20, 2022

fbartho May 20, 2022

IanVS left a comment

IanVS May 20, 2022

fbartho May 20, 2022

fbartho May 20, 2022

IanVS May 20, 2022

fbartho May 20, 2022

IanVS May 20, 2022

fbartho May 20, 2022

IanVS May 20, 2022

fbartho May 20, 2022

IanVS May 20, 2022

fbartho commented May 20, 2022

IanVS commented May 25, 2022

IanVS left a comment


		nodeToKeep.specifiers.push(...nodeToForget.specifiers);

		// The line numbers will be all messed up. Is this a problem?

Feature: importOrderMergeDuplicateImports #19

Feature: importOrderMergeDuplicateImports #19

Conversation

fbartho commented May 18, 2022

IanVS left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blutorange May 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fbartho May 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

IanVS left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fbartho commented May 20, 2022

IanVS commented May 25, 2022

IanVS left a comment

Choose a reason for hiding this comment

Feature: `importOrderMergeDuplicateImports` #19

Feature: `importOrderMergeDuplicateImports` #19

blutorange May 19, 2022 •

edited

Loading

fbartho May 19, 2022 •

edited

Loading