[WIP] feat!: migrate to constructs #1671
Conversation
| @@ -0,0 +1,541 @@ | |||
| { | |||
There was a problem hiding this comment.
I generated this for fun, just to see what the construct tree looks like. The paths look a tad ugly because "/" occurs a lot in file paths, but isn't allowed in construct paths, so they just get translated to "--". I wonder if there's a way to make this more natural, or maybe have a specific "projen-specific" path instead with a different delimiting scheme, etc
| /** | ||
| * Finds a JSON file by name in the given scope. | ||
| * @param filePath The file path. If this path is relative, it will be resolved | ||
| * from the root of the nearest project. | ||
| */ | ||
| public static tryFindJsonFile( | ||
| scope: IConstruct, | ||
| filePath: string | ||
| ): ObjectFile | undefined { | ||
| const isObjectFile = (c: IConstruct): c is ObjectFile => | ||
| c instanceof ObjectFile; | ||
| const absolutePath = path.isAbsolute(filePath) | ||
| ? filePath | ||
| : path.resolve(Project.ofProject(scope).outdir, filePath); | ||
| return scope.node | ||
| .findAll() | ||
| .filter(isObjectFile) | ||
| .find((file) => file.absolutePath === absolutePath); | ||
| } |
There was a problem hiding this comment.
By switching to constructs, escape hatching is more flexible since anyone can directly access construct.node. However I think these "tryFind" methods are still useful if you don't know where a file is generated from.
I'm not sure if this functionality should be on Project, or if it should be on the filetype classes instead. We could also just expose tryFind/tryFindFile in the Project class and just expose isXxx static methods on these classes instead.
(re: naming -- if we choose to make them static methods, we can't name them all tryFind because of aws/jsii#3410 so they have to be a little verbose)
|
you probably want a pr/do-not-merge on this one |
|
Closing for now as stale |
|
Implemented by #2974 |
Just an experiment.
Known issues:
Open questions:
constructor(scope: Construct, props: Props)in v1 of this PR.constructor(scope: Construct, id: string, props: Props)like most other CDK libraries? There is a constraint inconstructsthat sibling nodes must have different names, and this could get awkward if the IDs are not customizable.ProjectType.ofProjectType(scope)? I think the latter might be better long term.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.