Skip to content

Commit

Permalink
docs: Update ReadMe to include enum info
Browse files Browse the repository at this point in the history
  • Loading branch information
deadlydog committed Aug 13, 2023
1 parent 1743a47 commit 6485960
Showing 1 changed file with 25 additions and 14 deletions.
39 changes: 25 additions & 14 deletions ReadMe.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

This is a test repo to reproduce an issue I am having with Pester not finding the class type when it is defined in a separate file in the module, rather than directly in the psm1 file.

This repo implements several different approaches to using a class in a module to see what works and what doesn't.
This repo implements several different approaches to using a class and an enum in a module to see what works and what doesn't.

## The problem

Expand All @@ -15,13 +15,22 @@ However, it seems that if the class is defined in a separate file in the module
Even stranger, is that this issue does not happen on my local machine, but does happen on the build server with GitHub Actions.

## How to reproduce
## The experiment

This repo contains 3 modules:

1. One with the class defined in the psm1 file.
1. One with the class defined in a separate file and imported via a `using module` statement.
1. One with the class defined in a separate file and imported via dot-sourcing.
1. One with the class defined in a separate file and imported [via a `using module` statement](/src/ModuleWithClassInSeparateFileIncludedWithUsing/ModuleWithClassInSeparateFileIncludedWithUsing.psm1).
1. One with the class defined in a separate file and imported [via dot-sourcing](/src/ModuleWithClassInSeparateFileIncludedWithDotSourcing/ModuleWithClassInSeparateFileIncludedWithDotSourcing.psm1).
1. One with the class defined [in the psm1 file](/src/ModuleWithClassInPsm1/ModuleWithClassInPsm1.psm1).

Each module also contains Pester tests to test:

- The class can be used by the module functions.
- The class type can be used outside of the module.

In addition to defining classes in various ways and testing them, we also define and tests enums in the same ways to see if they suffer from the same issues.

## Reproducing the issue (e.g. running the experiment)

This repo defines a VS Code `test` task for running Pester locally, as well as a GitHub Actions workflow for running Pester on the build server.

Expand All @@ -36,26 +45,28 @@ When Pester runs on the build server with GitHub Actions though, the `using modu

The results of the experiment are as follows:

| | Class can be used by module functions | Class type can be used outside of module |
| ---------------------------------- | ------------------------------------- | ---------------------------------------- |
| Class imported with `using module` |||
| Class imported with Dot-sourcing | ✔️ ||
| Class defined in psm1 | ✔️ | ✔️ |
| | Class/Enum can be used by module functions | Class/Enum type can be used outside of module |
| --------------------------------------- | ------------------------------------------ | --------------------------------------------- |
| Class/Enum imported with `using module` | | |
| Class/Enum imported with Dot-sourcing | ✔️ | |
| Class/Enum defined in psm1 | ✔️ | ✔️ |

If we use `using module` to import the file with the class, then the class cannot be used by the module functions, and the class type cannot be used outside of the module.

If we dot-source the file with the class, then the class can be used by the module functions, but the class type still cannot be used outside of the module.

If we define the class in the psm1 file, then the class can be used by the module functions, and the class type can be used outside of the module.

Enums behave the same as classes with regards to these tests.

## Conclusion

The best approach, as of PowerShell version 7.1.3, is to define the class in the psm1 file of the module.
The best approach, as of PowerShell version 7.1.3, is to define the class/enum in the psm1 file of the module.

If you really want to have your classes in separate files, and you don't intend for the class types to be used outside of the module, then you can use dot-sourcing to import the class file.
If you really want to have your classes/enums in separate files, and you don't intend for the class/enum types to be used outside of the module, then you can use dot-sourcing to import the class file.

Hopefully future versions of PowerShell will allow us to use either `using module` or dot-sourcing to import the class file, and still be able to use the class in the module functions, and the class type outside of the module.
Hopefully future versions of PowerShell will allow us to use either `using module` or dot-sourcing to import the class/enum file, and still be able to use the class/enum in the module functions, and the class/enum type outside of the module.

I did not discover why the `using module` approach works locally, but not on the build server.
I assume something must be cached somehow, even between PowerShell sessions.
I assume something must be cached somehow on my machine, even between PowerShell sessions.
I am going to assume this is an anomaly with my machine though and trust the GitHub Action results above my local machine results.

0 comments on commit 6485960

Please sign in to comment.