fix: handle deeply nested whole exports #111

FredericEspiau · 2024-12-19T12:58:17Z

Fixes #109

But if you have a loop in your whole exports, now you are doomed 😬

FredericEspiau · 2024-12-19T12:59:07Z

lib/util/edit.ts

@@ -92,7 +93,7 @@ const createLanguageService = ({
  projectRoot: string;
  fileService: FileService;
 }) => {
-  const languageService = ts.createLanguageService({
+  return ts.createLanguageService({


Tell me if you want me to revert these kind of changes, I've got some OCDs about this kind of stuffs 😬

lib/util/edit.ts

FredericEspiau · 2024-12-19T13:00:22Z

lib/util/edit.ts

@@ -12,6 +12,7 @@ import { MemoryFileService } from './MemoryFileService.js';
 import { findFileUsage } from './findFileUsage.js';
 import { parseFile } from './parseFile.js';
 import { Output } from './Output.js';
+import * as Export from './export.js';


I've used namespaces to organise the code. This way you can do stuff like

Export.DeclarationWholeExport.isFileFound

Tell me what you think about this

I don't have any particular opinion about using namespace imports (besides, it's not an issue in terms of detecting unused code since tsr can detect these 😎

I’ve been thinking about this, but can we use import { foo } from 'foo' to keep the style consistent? Sorry for the confusion🙏

lib/util/edit.ts

lib/util/findFileUsage.ts

lib/util/parseFile.ts

kazushisan

Thank you for your awesome work 🚀

kazushisan · 2024-12-19T14:05:26Z

lib/util/edit.ts

@@ -536,13 +583,11 @@ export {};\n`,
  }

  if (changes.length === 0) {
-    const result = {
+    return {


actually, I created the result const intentionally so that I get the correct type inference without having to annotate the return type of the function. Would you mind reverting this?

https://www.typescriptlang.org/play/?#code/PTAEBcAsFNQMwPYBskIO4EsB2BzCBPAB1mzmgCdosBjEgZ1CwXFDUgEMW1Y12twAUCHgBXGuAwIs8ABQBKAFygA3kLCgNBYkoBE7HQG41mjQA8ldcOWw4jwk-gD8SsQBNocbNFd2wAX1AAHxVjE3AiaF0AI0NQzXwLKxtfE1BTZ1A3Dy8fYz8BODFqCSlZORCNDDhQGQBZTkgAOnI+VwQAW3lQAD5QRoBWctUTSnARcmlh1PDtUABydjnQdgZqKUsAGgFUtKU5xAQ5rZN8jXzt0FHxyYuNGcj5qKWV0DWsTdvQBMf2ciOL-LnYzcVh8FhQDAMe4KYyFcSSaQ4eRKVT2TTQ0B6WJosyJay4FIBYKo9ToiLRbGkjTfSz42x5ApFEqIrpTSrVOoNZqtDpdXoDIafN6WS7QOgiJAsAC8FWm5Pmi2Wq3W4GOqXM8wO-xOAk+VwmovFkqMZ11GmFLEoRulsru8rmTyVrxVaupeyiv21oHOGn10itEvARj8QA

It's your project mate, ask me and I'll do it 😄. This is done.

kazushisan · 2024-12-19T14:07:57Z

lib/util/export/wholeExportDeclaration.ts

+/**
+ * Whole export when the file is found within the destFiles
+ */
+export type FileFound = {


declaring a type which is almost the same seems a bit redundant. How about

export type FileFound = WholeExportDeclaration & { file: string }

In this kind of case what I usually is

type Base = { ... }; type SubCase1 = Base & { ... }; type SubCase2 = Base & { ... }; type Whole = SubCase1 | SubCase2;

Because Base isn't actually a type you can use as it's not really a WholeExportDeclaration, which has either file: string or file: null, WDYT?

kazushisan · 2024-12-19T14:09:15Z

lib/util/findFileUsage.ts

@@ -2,7 +2,8 @@ import ts from 'typescript';
 import { Vertexes } from './DependencyGraph.js';
 import { parseFile } from './parseFile.js';

-const ALL_EXPORTS_OF_UNKNOWN_FILE = '__all_exports_of_unknown_file__';
+const ALL_EXPORTS_OF_UNKNOWN_FILE = '#all_exports_of_unknown_file#';


I like your idea of using # for special keywords. Definitely better than my original implementation!

The best way to do it would be a Symbol though

kazushisan · 2024-12-19T14:11:53Z

lib/util/edit.ts

+ *
+ * No need to memoize this function because `parseFile` already memoizes the file parsing.


Suggested change

*

* No need to memoize this function because `parseFile` already memoizes the file parsing.

I think this comment is too much [nit]

lib/util/export.ts

kazushisan · 2024-12-19T14:23:48Z

lib/util/edit.ts

+  files,
+  fileNames,
+  options,
+  filesAlreadyVisited = new Set<string>(),


I think that this field is exposing unnecessary choice/information outside of the function's boundary. Can this be declared inside the function?

function foo() { const visited = new Set(); // do something then deeply(theOtherArgs, visited) }

or maybe using a stack instead of recursively calling functions is better to have a shared context. (converting to using a stack is just a suggestion, not a must)

Done, I've kept the recursion because I didn't know how to do it with the stack 😄

kazushisan · 2024-12-19T14:26:20Z

lib/util/edit.test.ts

@@ -1130,6 +1130,26 @@ export const b = 'b';`,
      assert.equal(fileService.exists('/app/a_reexport.ts'), false);
      assert.equal(fileService.exists('/app/a.ts'), false);
    });
+
+    it('should look for deeply nested whole re-export without removing files', () => {


I think the logic not supporting loops is acceptable as long as the behavior is defined 👍 Can you add a test case to assure what happens when there's a loop?

Well your test case will just hang until you stop it, so there isn't much I can do about this

kazushisan · 2024-12-19T14:28:34Z

lib/util/edit.ts

@@ -12,6 +12,7 @@ import { MemoryFileService } from './MemoryFileService.js';
 import { findFileUsage } from './findFileUsage.js';
 import { parseFile } from './parseFile.js';
 import { Output } from './Output.js';
+import * as Export from './export.js';


I don't have any particular opinion about using namespace imports (besides, it's not an issue in terms of detecting unused code since tsr can detect these 😎

kazushisan

Thank you!