[FEATURE] Handle non "project.json" based projects

[GuyLescalier]

Hi @pmowrer ,

I have used your package for javascript projects and would like to use it for .NET Core projects.

By looking at your code, very few is specific to "project.json" files. The only dependencies are for locating the file in order to filter the commits and for getting the project name.

I tried to put all those references in a separate file in order to have multiple implementations for different project types :

const pkgUp = require("pkg-up");
const readPkg = require("read-pkg");
const getPackagePath = async () => {
    return await pkgUp();
}
const getPackageName = async () => {
    return (await readPkg()).name;
}
module.exports = {
    getPackagePath,
    getPackageName
};

My problem is I cannot figure out how to retrieve a parameter which would indicate the project type (defaulting to npm for backward compatibility) in order to select the corresponding implementation.

Do you think it is possible and do you have an idea how ?

[GuyLescalier]

There doesn't seem to be a way to give a parameters through the extends option so I went an other way. I added "top level" files so it should be possible to do this:

• "extends": "semantic-release-monorepo"
• "extends": "semantic-release-monorepo/npm"
• "extends": "semantic-release-monorepo/dotnet" Do you want to take a look (https://github.com/zedtk/semantic-release-monorepo/tree/feat/dotnet) or should I just create a pull request ?

[pmowrer]

Hi @GuyLescalier,

Thanks for the thoughtful issue/PR and sorry for the wait!

I'm not familiar with .NET workflows... would you mind providing some more context? Is this something that semantic-release supports? This repo is meant to augment semantic-release specifically for the purposes of applying it to a monorepo. I would expect anything to do with supporting .NET to be handled in a separate semantic-release plugin rather than baked into this lib. Is there something like that out there?

[GuyLescalier]

Hi, As you say semantic-release tries to be agnostic of the technical stack. For example, you need to use @semantic-release/npm to handle npm projects and I developped a plugin @zedtk/semantic-release-nuget to handle dotnet/nuget projects. The only difference between these stacks (that concerns semantic-release) is the format of the file (project.json or .csproj) that holds the project metadata (name, version, etc.).

Yet in semantic-release-monorepo you need information from the project (path, name, version). And you provided an implementation assuming the project file would be a project.json.

So my proposition was to separate the code which is responsible to retrieve those informations. That way you can have multiple implementations for different types of projects.

Actualy the best way would be to externalize completely this part instead of having semantic-release-monorepo provide thos multiple impementations. Until today I didn't think it could be possible. But I saw another feature request (https://github.com/pmowrer/semantic-release-monorepo/issues/110) mentionning global configuration. This would allow to set in the global configuration the name of the plugin responsible for retrieving project scoped information and dynamicaly require it.

[GuyLescalier]

Hi again 😄 I did some tests with global config and was able to inject functions. My release.config.js file: `const readPkg = require('read-pkg');

module.exports = {
  plugins: [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
  ],
  getProjectName: async () => (await readPkg()).name,
  getProjectVersion: async () => (await readPkg()).version,
}`

So maybe that would be the best way to do it. You would have a default "npm based" implementation for the functions that read package metadata. And everyone could use global config to override those for different kinds of project files. What do you think ?

[snebjorn]

Any progress on this? I was looking into making a .NET monorepo :)