Delete test-gc-sweep-tests

[Abe27342]

Description

This makes progress toward #15917 by deleting test-gc-sweep-tests, which is not needed anymore as per @agarwal-navin.

PACKAGES.md was updated using flub check layers --info ./build-tools/packages/build-tools/data/layerInfo.json --md ..

[msfluid-bot]

⯅ @fluid-example/bundle-size-tests: +30 Bytes

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	448.83 KB	448.84 KB	⯅ +6 Bytes
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	239.47 KB	239.47 KB	⯅ +2 Bytes
loader.js	154.4 KB	154.4 KB	⯅ +4 Bytes
map.js	46.66 KB	46.66 KB	⯅ +2 Bytes
matrix.js	146.59 KB	146.59 KB	⯅ +2 Bytes
odspDriver.js	92.31 KB	92.32 KB	⯅ +6 Bytes
odspPrefetchSnapshot.js	43.64 KB	43.64 KB	⯅ +4 Bytes
sharedString.js	163.26 KB	163.27 KB	⯅ +2 Bytes
sharedTree2.js	279.92 KB	279.92 KB	■ No change
Total Size	1.73 MB	1.73 MB	⯅ +30 Bytes

---

Baseline commit: 56bd728

Generated by 🚫 dangerJS against f8122bf

[curtisman]

I am wondering if this would lose typing info for intellisense?

[Abe27342]

nope. Typescript looks for .d.ts files adjacent to the js file when using an import statement from an esnext module. You can see their doc has similar syntax.

Overall, my impression is that the ecosystem is a lot more mature w.r.t. supporting fully qualified import paths than the last time I checked. E.g. the changes I had to make to webflow's webpack config to make it understand this import were pretty trivial:

				// This ensures that webpack understands fully-specified relative module imports.
				// See https://github.com/webpack/webpack/issues/13252 for more discussion.
				extensionAlias: {
					".js": [".ts", ".tsx", ".js"],
					".mjs": [".mts", ".mtsx", ".mjs"],
				},

The 2 biggest issues I encountered which I don't have ideal solutions for were:

1. VSCode will generate incorrect autocomplete imports. This behavior is configurable via "typescript.preferences.importModuleSpecifierEnding", but I don't think there's a way to tell VSCode to scope the setting to particular subsets of our repo. This issue would go away if we ever convert to full ESNext modules only (which is probably a ways off).
2. I turned off ESLint's "import/no-unresolved" rule for relative imports. We could fix this if we wrote our own ESLint import resolver, but I didn't find one that worked out of the box and IMO the maintenance burden is probably not worth the value the lint rule provides for relative imports.