Output cross-language names in generated docs#130
Conversation
Each `Target` implementation can contribute to this process by providing two static functions that allow the sphinx generator to obtain: * The package coordinates in the "standard" registry (e.g: maven) for an assembly * The native name (or names) for a given `Type`. There can be multiple names in case the artifacts can be used across different languages, for example Javascript & TypeScript share names, but `InterfaceType`s are not visible in Javascript. The C# names are not included, because the process to come up with those names is factored in the C# code, and the dis-ambiguation is complex to reproduce. This omission will be corrected at a later point in time. Fixes #74
| .usage('Usage: jsii-pacmak [-t target,...] [-o outdir] [package-dir]') | ||
| .option('targets', { | ||
| alias: 't', | ||
| alias: ['target', 't'], |
|
|
||
| export interface TargetConstructor { | ||
| /** | ||
| * Provides the coordinates of an assembly in the usual package repository for the target. |
There was a problem hiding this comment.
Explain what "coordinates" mean in this context. Maybe provide example(s)
| && (parsedVersion.major !== 0 ? parsedVersion.inc('major') | ||
| : parsedVersion.inc('minor')); | ||
| return { | ||
| repository: 'Maven', |
| * @param assm the assembly for which coodinates are requested. | ||
| * @return the name of the repository, and the coordinates within it. | ||
| */ | ||
| toPackageCoordinates?: (assm: spec.Assembly) => { repository: string, coordinates: string }; |
There was a problem hiding this comment.
I thought so. But how to we format the link? I kinda punted this for later, but if you have an idea...
There was a problem hiding this comment.
In the sphinx docs? Maybe something like:
<a href="link">View in ${repository}</a>
| }; | ||
| } | ||
|
|
||
| public static toNativeNames(type: spec.Type, options: any) { |
There was a problem hiding this comment.
Reuse this method in java_generator.toNativeFqn
There was a problem hiding this comment.
I wanted to, but the java generator's toNativeFqn only has a fqn(string) available, because it needs to also be able to render names for TypeRefs.
| public static toPackageCoordinates(assm: spec.Assembly) { | ||
| return { | ||
| repository: 'NPM', | ||
| coordinates: JSON.stringify({ [assm.name]: `^${assm.version}` }, null, 2) |
There was a problem hiding this comment.
Maybe we can also do something like:
npm i ${assm.name}@${assm.version}Add another field to coordinates? (usage)
There was a problem hiding this comment.
That's a good idea.
| this.code.indentation = 3; | ||
| } | ||
|
|
||
| public async load(packageRoot: string) { |
There was a problem hiding this comment.
I wonder if we shouldn't just include set of target constructors as part of load. It is available in the outer scope.
There was a problem hiding this comment.
I guess we can couple everything to everything else. Doesn't mean it's a good idea...
There was a problem hiding this comment.
Let's keep it like this for now until the 2nd case where a generator will need this info
|
|
||
| .. group-tab:: Maven | ||
|
|
||
| :: |
There was a problem hiding this comment.
Shouldn't that be .. code-block:: or something?
There was a problem hiding this comment.
When using code-block, the "title" of the tab must be a valid syntax highlighter... And that's to the experience I want (would have Maven Central tab require to be named XML).
There was a problem hiding this comment.
I think the titles should actually be the language name and not the repository name.
Also, you could have full control over the tab name if you just embed a code-block in it:
.. group-tab:: MyTitle
.. code-block:: js
console.log('hello, world')
There was a problem hiding this comment.
Mind you, this will not render the same. But since we want to possibly also have a URL and "usage", this is probably something that's going to fly anyway :)
|
|
||
| .. tabs:: | ||
|
|
||
| .. group-tab:: Maven |
There was a problem hiding this comment.
The names of the group tabs should align with the names of the code tabs, so they will switch together
There was a problem hiding this comment.
Can do, but I am not a fan of labelling the maven POM dependency blob with Java. In this case, what if we want to also provide a gradle instruction?
There was a problem hiding this comment.
We can also provide gradle instructions (and probably also "yarn").
|
|
||
| .. code-tab:: javascript | ||
|
|
||
| Value |
There was a problem hiding this comment.
I think typescript and javascript also need the require statement:
JavaScript:
const { Value } = require('jsii-calc-lib');TypeScript:
import { Value } from 'jsii-calc-lib'There was a problem hiding this comment.
Didn't we say we wanted to encourage people using import lib = require('lib');? This would go against this guideline...
There was a problem hiding this comment.
It's true. But I can't think of a way to express this in a nicer way, and the name of the import is important here. Maybe:
import jsiiCalcLib = require('jsii-calc-lib');
jsiiCalcLib.ValueBut that looks ugly.
I think import {} is fine here. The CDK examples and code should still use namespaced imports, but this is "The Right" way to express this in JS/TypeScript.
|
Note that this will change the output directory to "js" instead of "npm", and will likely break our publishing scripts |
|
@eladb The name change is intentional - other folders are named after the language, not the repository. |
|
@RomainMuller I am aware. Just calling it out. I think we'll not include this change in the release today anyway. |
|
The rename was "copied" under this PR, so the output directory of javascript assets shouldn't be a concern any longer. |
eladb
left a comment
There was a problem hiding this comment.
.NET is missing. Let's not leave it behind anymore...
| * | ||
| * @return Information about the assembly in the various package managers supported for a given language. | ||
| */ | ||
| toPackageInfos?: (assm: spec.Assembly) => { [language: string]: PackageInfo }; |
There was a problem hiding this comment.
Provide some examples here. Specifically, it's not clear why would this return a hash instead of just PackageInfo (I understand this is for the typescript/javascript case, but maybe worth mentioning as an example)
There was a problem hiding this comment.
Added a couple of examples.
| * | ||
| * @return the native reference for the target for each supported language. | ||
| */ | ||
| toNativeReference?: (type: spec.Type, options: any) => { [language: string]: string }; |
| * plain string (documentation should render as a pre-formatted block of text using monospace font), or an object | ||
| * describing a language-tagged block of code. | ||
| */ | ||
| usage: { [label: string]: string | { language: string, code: string } }; |
| */ | ||
| function formatLanguage(language: string): string { | ||
| switch (language) { | ||
| case 'csharp': |
There was a problem hiding this comment.
Haven't seen the .NET target changes. Should we at least emit a C# option there?
There was a problem hiding this comment.
Since we're not publishing anything to Nuget yet, I figured it was probably best if our documentation doesn't start pointing people at places that don't exist...
Each
Targetimplementation can contribute to this process by providingtwo static functions that allow the sphinx generator to obtain:
assembly
Type. There can be multiplenames in case the artifacts can be used across different languages,
for example Javascript & TypeScript share names, but
InterfaceTypesare not visible in Javascript.
The C# names are not included, because the process to come up with those
names is factored in the C# code, and the dis-ambiguation is complex to
reproduce. This omission will be corrected at a later point in time.
Fixes #74
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.