-
Notifications
You must be signed in to change notification settings - Fork 83
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
Easier identification of experimental modules #116
Comments
For the record, I think we're going to bring pain onto ourselves if we want to split off experimental APIs into a separate package. Here are some thought exercises:
The better solution is to vend 2 different flavors of CDK from a single codebase:
This will solve all issues mentioned above:
Originally posted by @rix0rrr in https://github.com/_render_node/MDIzOlB1bGxSZXF1ZXN0UmV2aWV3VGhyZWFkMjMwOTM0MzY2OnYy/pull_request_review_threads/discussion |
@rix0rrr how will this work for typescript modules? |
We remove the hidden APIs from the The one I don't have a solution for will be JavaScript users, but how will they know certain functions exist in the first place? And don't JS editors still use |
Sounds tricky but might work :-) I am not concerned about JavaScript as they use .d.ts and the reference documentation as well. We can consider to add "@internal" to all "@experimental" elements. I think auto-generating an experimental variant of the library is an interesting idea. With the mono-bundle (#6) it might even be an awesome developer experience. We can prototype this together with the prototype for mono-cdk. |
A few more thoughts:
|
Yeah, that doesn't make sense, and I'm having a hard time thinking of models in which we can express this. In C, we would model this using opaque pointers. That would correspond to the type (name) That would express the desired intent, but TypeScript's structural typing may play havoc on us (for instance, APIs that expect to take a We may need to force TypeScript into nominal typing.
In the most base approach, it's fine to ignore the peerDependencies requirements. You can substitute your own, knowing that they will work. Slightly more sophisticatedly, semver has some semantics around version extensions that might come in useful ( |
How will it work? One of the imports will fail... |
Oh wait, now I understand that you want to release the experimental module under the same name but with a different version. Ok that’s interesting. |
I'm curious. Is the |
Description
The AWS CDK is a large class library which is released through a single version. In order to allow innovation and quick iteration, we decided to leverage the model employed by the node.js project and tag APIs either as STABLE or EXPERIMENTAL (as described in our user guide).
Technically, each API element (class, enum, method, property) can be have a stability tag. If it is not tagged, it will inherit it's stability from it's parent, all the way up to the module level.
Practically, the current "high resolution" module causes confusion and oftentimes results in users coding against experimental APIs without their knowledge. This is because most of the construct library's modules include "CFN resources" which are always STABLE, while other constructs can still be EXPERIMENTAL. Users are also not accustomed to reviewing the API documentations for every module they use.
The purpose of this RFC is to improve the experience around consuming experimental modules, so that it will be easier for customers (in the common case) to acknowledge that they are using experimental APIs.
@ccfife proposes a solution where experimental constructs will be available only under the "@aws-cdk/aws-xxx-experimental" module and only move to the main module as they stabilize. The main module initially will only include "CFN resources" (which are stable).
Progress
The text was updated successfully, but these errors were encountered: