Comments (7)
This sounds like a reasonable feature! Breaking it up into individual project types which you can use independently would be useful, though I think it's still important to keep the existing interface so that users can choose to use the more opinionated option to get up and running quickly if they're happy with it :)
Interesting though that you're experiencing an issue where the cdk construct is building before the model builds - the dependency should be set up automatically here: https://github.com/aws/aws-prototyping-sdk/blob/mainline/packages/open-api-gateway/src/project/open-api-gateway-ts-project.ts#L249-L250 - I believe NX should honour the dependency graph so long as each package is in the yarn workspace.
from aws-pdk.
Agreed on the first statement, maybe "pull out" wasn't the best terminology as not everybody wants to use Smithy code generation and would like to stick with the Open API opinionated construct.
For the second one, I think this has to do with projen
and nx
conflicting with each other for some reason and need to dive deeper into it. For example, cloning a repo and getting started works fine:
- Clone the repo, then cd into it
- yarn install
- npx projen
- npx nx run-many --target build --all
Running npx nx run-many --target build --all
usually works as well. But there's certain oddities, like for example when I add a dependency to a new SmithyApiGatewayTsProject
it intermittently fails with the same error discuss on another issue "failed to get @prototype/ssdk" because it's looking for the public repository first before locally (even when the package is in the workspace). It's not till I do some combination of yarn install
at the root and npx nx run-many --target build --all
again then will projen
work.
The only thing I have seen is how node_modules
are laid out. Everything works fine when the root nx monorepo has almost all of the node_modules at root (including the autogenerated SDK) and all subprojects usually have a node_modules
that are just symlinks. But for some reason (still trying to determine reproducible steps), the subpackage api
will instead download it's own node_modules (like it's the only repo that exist, which is why I think it has something to do with projen
). It's not till I run a yarn install
at the root that all of the sub packages node_modules
are "hoisted" up to the nx monorepo root.
Note: I say almost all, because the generated SDK node_modules are not hoisted and shared all the way up to root. It instead just takes the entire directory (it's node modules and all) and hoisted it to root as a single unit. Not really a bad thing, just a weird thing
from aws-pdk.
Reproducing steps (sent a link to an example repo):
- Add a dependency to the project, then run
projen
- An unexpected error occurred: "https://registry.yarnpkg.com/@prototype%2fsdk: Not found"
- Run
yarn install
at the root- Then run projen again and it works
from aws-pdk.
The above error seems to be a result of an underlying limitation of projen and not the prototyping SDK. When projen runs the default task (I.e. synthesizes and download dependencies). It looks like it essentially 'cd's into the directory to perform the operations. Because the cwd is no longer the root monorepo, it doesn't know that the other package exist locally and keeps trying to go out to npm to find it.
Hoisting all of my dependencies to the top (in monorepo) solves the issue.
May be easier to orchestrate when Smithy code generation becomes its own package
from aws-pdk.
This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label.
from aws-pdk.
Closing this issue as it hasn't seen activity for a while. Please add a comment @mentioning a maintainer to reopen. If you wish to exclude this issue from being marked as stale, add the "backlog" label.
from aws-pdk.
This is now addressed by type-safe-api
! This supersedes open-api-gateway
and provides a more modular directory structure. It also exports TypeSafeApiModelProject
which will create a project which contains the Smithy or OpenAPI model. The build task generates an openapi spec- the smithy one can be further customised to add more projections however (eg TypeScript server SDK).
The generated spec can then be used with the TypeSafeRestApi
CDK construct if you want to deploy the api gateway resources, but the integrations won’t be type safe :). This should be enough to use the TypeScript server SDK instead of the handle wrappers provided by PDK :)
Note that you may need to add a TypeScriptProject
for the shell of the TSSSDK that’s parented by the monorepo, and include a preCompile task to copy the generated code from “smithy-output” into its source directory- that way the project will be available at “install” time so yarn etc will find it, but the code is generated at build time :)
from aws-pdk.
Related Issues (20)
- [BUG] Upgrading core pdk code results in reverting back to the original versions. HOT 5
- [BUG] Passing a smithy api to Infrastructure results in namespace being prepended in the variable and class name HOT 2
- [BUG] type-safe-api appending "operation" to some operationIds HOT 3
- [BUG] Python Lambda handlers in type-safe-api can't import runtime module HOT 1
- [DOCS] Getting Started - Incorrect JDK install links HOT 2
- [BUG] typesafe-api code generation script doesn't handle spaces in the directory path HOT 2
- [BUG] (short issue description)Codegen for mocks fails on filename case mismatch. HOT 3
- Publishing vv0.23.42 to maven failed
- [BUG] (Maven plugin executions synthesized incorrectly) HOT 2
- [FEATURE] (allow sorting of pom.xml plugins for maven) HOT 2
- Publishing vv0.23.44 to maven failed
- [FEATURE] Add support for RuleActionOverrides for WAF using TypeSafeApi constructs
- Publishing vv0.23.44 to maven failed HOT 1
- [BUG] several deprecated dependencies in monorepo-ts template
- [BUG] MonorepoTsProject should lint .projenrc.ts and projenrc/**.ts
- [FEATURE] Add ability to customize outputSpecLocation S3 bucket for type-safe-rest-api PrepareApiSpecCustomResource HOT 1
- [BUG] (type-safe-api) install fails on python runtime package with missing README HOT 1
- [BUG] type-safe-api build fails when AWS_PDK_VERSION is not set in the environment
- [FEATURE] (type-safe-api) only require OpenApi Generator when API changes HOT 1
- [FEATURE] Return error message sent from backend instead of standard message in ResponseError
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aws-pdk.