Closed leojonathanoh closed 2 years ago
Good idea.
I'm still thinking of how to best name the file though. modulemanifest.ps1
isn't adequately descriptive. @leojonathanoh
@joeltimothyoh thinking about this now, i can think of some downsides to this change:
./src
artificially gives a user an impression that the .ps1
has something to do the actual module's source code, when it really doesn't. .ps1
is really a template / templating object for .psd1
, and putting it in ./build/
might actually be better because it separates templates from the actual generated files. ./build/definitions/modulemanifest/definition.ps1
actually gives meaning to the .ps1
suggesting that it is an object definition pertainting to the .psd1
. The new path does not provide such a meaning.So thinking about it now, i'm not sure this is a good idea anymore.
if we decide not to implement this change, perhaps we can update the existing sample https://github.com/theohbrothers/PSModulePublisher/blob/v0.4.0/docs/samples/build/definitions/modulemanifest/definition.ps1.sample to dynamically determine the Export*
keys from $PSScriptRoot/../../../src/public
, see the OP. E.g. https://github.com/theohbrothers/Position-ExplorerWindow/blob/v1.3.1/build/definitions/modulemanifest/definition.ps1#L25-L27
So thinking about it now, i'm not sure this is a good idea anymore.
Good idea.
if we decide not to implement this change, perhaps we can update the existing sample https://github.com/theohbrothers/PSModulePublisher/blob/v0.4.0/docs/samples/build/definitions/modulemanifest/definition.ps1.sample to dynamically determine the *Exported from $PSScriptRoot/../../../src/public, see the OP.
I think dynamic determination would be a workaround. Besides, the definition file is meant to represent a pure hashtable object.
@joeltimothyoh if the .ps1
is contains merely repo-specific hardcoded values, then one might as well simply update .psd1
after generating the .psd1
. The point is to make the generator an dynamic one so that definition.ps1
only needs to be updated with as few repo-specific values, and should be reusable across projects.
Thing is again it's meant to be a manifest definition, not a generator. If it's changed to a generator then the file, generate code, and docs have to be revised to reflect so. @leojonathanoh
@joeltimothyoh definition.ps1
is a definition for a .psd1
. But a .psd1
is a definition of a module. The problem with definition.ps1
is that it is a script and not a .yml
or .json
, so putting it inside a src/<module>
will be confusing. And as i point out, there's no convention to generating a .psd1
. That's the problem with all of these package managers.
is that it is a script and not a .yml or .json
It might be a .ps1
script , but it really is designed to just contain an object convertible to json or yaml.
so putting it inside a src/
will be confusing.
Yes so it's better to leave it at its present location. @leojonathanoh
i guess we're settled. will close.
on the point of using a dynamic defintition.ps1
for Export*
keys, i'm still inclined to do it just because .ps1
can do that but .yml
and .json
cannot. https://github.com/theohbrothers/PSModulePublisher/issues/8#issuecomment-950713055
It’ll be a misuse of the definition file just because it’s in .ps1
.
Current
Use
./build/definitions/modulemanifest/definition.ps1
as module manifest definition file.Expectation
Use
./src/<MODULE>/modulemanifest.ps1
as module manifest definition file.Discussion
As was discussed in https://github.com/theohbrothers/ItemLinkManagement/pull/2#issuecomment-890544601, The best place to place the modulemanifest would be to be right beside the
.psd1
or.psm1
where most developers would expect. Also, in that location the modulemanifest would see the same folder structure as the.psm1
and hence be able to populateExported*
keys of the module manifest definition dynamically.