use case insensitive comparison when searching for dependencies between fable packages

[ThisFunctionalTom]

This should fix the Issue 3833

[MangelMaxime]

/run fantomas

[github-actions]

Failed to run : https://github.com/fable-compiler/Fable/actions/runs/9436837670

[MangelMaxime]

/run fantomas

[github-actions]

Failed to run fantomas: https://github.com/fable-compiler/Fable/actions/runs/9436844381

[MangelMaxime]

@ThisFunctionalTom Where you able to test it using a locally build version of Fable (via ./build.sh package)?

Running ./build.sh package will give you instruction on how to use that local version of Fable. I am asking, because this fix is not something we can catch easily using the CI I think.

[ThisFunctionalTom]

@ThisFunctionalTom Where you able to test it using a locally build version of Fable (via ./build.sh package)?

Running ./build.sh package will give you instruction on how to use that local version of Fable. I am asking, because this fix is not something we can catch easily using the CI I think.

I debuged fable.cli on my project with a breakpoint and looked at the file . I thought about adding tests for sortFablePackages which shouldn't be that hard because it is a pure function but I didn't find the right place where to put the tests. Do you have an idea where should I put the tests?

I will try running it with build.sh later but I would probably need to use build.cmd because I am on windows.

[MangelMaxime]

I will try running it with build.sh later but I would probably need to use build.cmd because I am on windows.

Yes should be the same.

Do you have an idea where should I put the tests?

Perhaps the tests/Integration/Integration/Fable.Tests.Integration.fsproj project could be the place for it? It seems like we are testing some internal APIs from Fable in it.

Or if we need to full project setup to test it, then we can create a new project under tests/Integration/ProjectConfigs and compile / run it here

Fable/src/Fable.Build/Test/Integration.fs

Lines 43 to 46 in 1a1854a

	testProjectConfig "DebugWithExtraDefines" (Some "Debug")
	testProjectConfig "CustomConfiguration" (Some "Test")
	testProjectConfig "ReleaseNoExtraDefines" None
	testProjectConfig "ConsoleApp" None

I think if the first one works then this is enough.

[ThisFunctionalTom]

Oh, I cannot test it because the function sortFablePackages and type FablePackage is not public (they are not in the fsi file).

In our projects we make testable functions internal and add [assembly:InternalsVisibleTo("MyTestAssembly")] to expose internal functions and types to test projects.

Should I do this? Is this compatible with fable repository coding style? Is there another way to test private functions?

[ncave]

I think it's fine as proposed, the spec says that package ids are case-insensitive.

[MangelMaxime]

Let's keep it simple and merge the PR as is.

[MangelMaxime]

This has been released