-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
monorepo multi-team/multi-project folder structure #158
Comments
hygen looks for the first .hygen.js file it finds walking up from your current directory to the root directory. Sharing as in multiple directories providing generators to all, then no, not yet, but I'm working on finding the right way to allow for that. Duplicate generator names is the sticking point there. Using Otherwise the philosophy is to use In your example, and assuming you didn't set If you had
Then |
Yup just to re-confirm, what @anithri explained is spot on. |
Just ran up a similar issue myself. I'm using Hygen in a monorepo setup where I'd like to share some templates (eg: React component generator), and also have templates scoped to packages (eg: Gatsby page generator). If there was some way Hygen could crawl up the tree until it finds a suitable template that would be awesome. Using the above example it would be great if you called a generator from within |
Happy to push this suggestion forward. Looks like a few solutions can be had:
thoughts? |
Yeah I think option 2 would be great. I think accidentally calling a generator you didn’t create from higher in the tree is a very niche edge case, and IMO duplicated template names are a non-issue because it’ll call the first it finds. This is the same as the configs for other popular tools — eg: Babel, uses the first babelrc it finds from the cwd it was called from. You could actually consider that a feature, for example if I had a top level |
@seaneking I think you're describing the first option @jondot wrote, which is to stop looking for template files or a config file after you've found one from wherever you started. I would tend to favor that as well. If we opt for crawling up and inheriting anything upwards it could make for some confusing cases since at what point do we stop looking for templates. It also begs the question about what is the stop condition. |
Hmm how I read 1. was that Hygen would stop looking beyond the CWD if it doesn't find an appropriate template. Maybe @jondot can clarify 😅 I agree that inheriting would be weird and confusing. But I don't think searching for templates up the tree until it find the appropriate generator falls under that scenario. |
So to sum up:
|
Ah, I was thinking multiple _template folders. Ie: Hygen would look for the closest generator specified. I could have a root level That said I think the behaviour outlined in 2 (searching up the tree for _templates rather than using an env variable) is an improvement regardless. |
Yea searching up is definitely an improvement. Would also be nice to keep the env variable method of specifying as well. I think what's also missing today is a way to specify a |
+1 for this, we have a giant monorepo with multiple realms of dev-tasks, thus: #!/usr/bin/env node
const fs = require('fs');
const path = require('path');
const cwd = process.cwd();
const signature = "./_templates";
var base = cwd;
var defaultTemplates = '';
while (true) {
var p = path.resolve(base, signature);
if (fs.existsSync(p)) {
defaultTemplates = p;
break;
}
else {
if (base == '/') { throw new Error("Templ folder not found!"); }
base = path.resolve(base, '../');
}
}
process.argv.splice(0, 2);
var p = require('child_process').spawn('hygen', process.argv, {
env: {
...process.env,
'HYGEN_TMPLS': defaultTemplates
}
});
process.stdin.pipe(p.stdin)
p.stdout.pipe(process.stdout)
p.stderr.pipe(process.stderr) searches parent directory for signature & injects into HYGEN_TMPLS, works for me now.. hope this helps |
@jondot, is there any update on this request? I was looking at Use Generators From a Single Place and was wondering if that's the solution for this. Overall, it would be great to have:
|
This is how typescript, eslint and babel work btw. I think if you document it, then people wont find it confusing at all. |
We actually don't need anything specific to monorepos. all we need here is for the i'd suggest that you migrate hygens configuration system to cosmiconfig. it handles all the problems of finding config files and allows us to choose what ever fileformat we want (but i'd hope you choose to implement the typescript loader). merging configs is upto the repo custodians, and is as simple as using js/ts configs combined with |
I was able to achieve a custom template search logic using for example, this logic searches for templates from the current directory up to parent folders
|
Just to give an example of calling hygen with
works great for my use case of a template system outside of a repo |
Hey guys, future user of hygen here. I just read the docs, and I'm already a fan of hygen! I'm thinking of migrating moon-launch to hygen, and I'm checking if I'm not going to paint myself into a corner (again). So far, I'm loving everything about it! One key thing for me is the ability to register new template locations. In moon that can be done by setting an array of template locations in I think that's the best approach. We won't need hygen to discover templates at all if we can tell it where all of them are :) Here's my suggestion for a new type templates = string | Array<string | {
path: string;
prefix?: string;
}> What about conflicts?If two locations have generators with the same name and using the same prefix, there will be a conflict and it needs to be resolved. But first... Why handle conflicts instead of forcing uniqueness via prefix? It allows for a very powerful mechanism that promotes reusability. Imagine there's an awesome template package that does a lot, but I want to replace one of its generators. Instead of forking it, understanding its code, and modifying it, I can simply add a generator to my project and setup hygen to use Proposed solution Instead of trying to come up with clever algorithms that will be confusing and take ages to get right (as in any package manager ever), let's just let the user decide what to do. Specifically, suggest the addition of another property to
I think this strategy should be fairly easy to implement. In the future, a btw, sorry if this was already proposed. I looked but didn't find it anywhere. |
The hygen FAQ says that it was built "to solve developer effectiveness in a multi-team, multi-module monorepo", however I'm curious about how to use it for that?
From reading through the docs, and your medium post I didn't get a sense of how one could have templates co-located within the different projects, but still be able to call hygen from the top level.
Would something similar to this structure work?
Or does hygen need to run within the same directory as the
.hygen.js
file?Thank you again for some a declarative approach to code gen tooling.
The text was updated successfully, but these errors were encountered: