Skip to content
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

[FEATURE] Versioninfo enrich with manifest infos #554

Merged
merged 41 commits into from
Jan 26, 2021

Conversation

tobiasso85
Copy link
Contributor

@tobiasso85 tobiasso85 commented Nov 27, 2020

Enrich task generateVersionInfo, such that the created version-info.json file contains new sections in the json structure:

  • manifestHints: for each library (in each library's json structure)
  • components: global (top level in the json structure)

manifestHints

The manifestHints section contains the libraries dependencies (fully resolved).

The resolved dependencies are

  • lazy
    • if parent dependencies are also lazy
  • non-lazy
    • if lazy is not defined for this dependency and it has no lazy parent
    • if there is the same dependency defined lazy but the current one isn't (non-lazy wins on the same level)

sample:

{
  "name": "sap.x",
  "version": "1.85.0",
  "manifestHints": {
    "dependencies": {
      "libs": {
        "sap.m": { },
        "sap.ui.core": { },
        "sap.ui.layout": { },
        "sap.ui.unified": {
          "lazy": true
        }
      }
    }
  }
},

components

The components section contains all components which are embedded by the libraries.
Each component has:

  • the including library
  • manifestHints
  • hasOwnPreload. It indicates that embeds points to subcomponents and embeddedBy points to parent components

sample:

  "components": {
    "sap.x.sub": {
      "library": "sap.x",
      "manifestHints": {
        "dependencies": {
          "libs": {
            "sap.m": {},
            "sap.ui.core": {},
            "sap.ui.layout": {},
            "sap.ui.unified": {
              "lazy": true
            }
          }
        }
      }
    },

return resolvedCache.get(libName);
}
const manifestHint = manifestHints.get(libName); // lib.c
console.log(`:processing: ${libName}`);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove/rewrite to logger before final submit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

const manifestContent = await manifestResource.getString();
const manifestObject = JSON.parse(manifestContent);
// TODO extract manifestHints
const manifestDependencies = manifestObject["sap.ui5"]["dependencies"];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Existence of a "sap.ui5" entry is not guaranteed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

*
* @example
* {
* sap.chart: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not an example for the above typedef (incomplete)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

return filePath.substr(0, filePath.length - "manifest.json".length) + subPath + "/manifest.json";
}
return filePath;
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better use something like path.posix.resolve. See manifestCreator.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the full power of posixPath:

return posixPath.resolve(posixPath.dirname(filePath), subPath, "manifest.json");

if (existingEntry) {
Object.keys(existingEntry).forEach((libName) => {
if (!existingEntry[libName].lazy && newLibs[libName] && newLibs[libName].lazy) {
newLibs[libName] = {};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Essentially, this is meant to be a delete newLibs[libName].lazy. Maybe better write it as this. If we ever add other information per library object (e.g. minVersion), this line doesn't cause extra work.

If you want to avoid the delete, set the property to undefined. Later serialisation to JSON will omit the undefined properties.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

*/
const setManifestHints = (manifestHints, libName, newObject) => {
const existingEntry = manifestHints.get(libName);
const newLibs = merge(existingEntry && existingEntry, newObject);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"magic"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

};

const merge = (existingEntry, newObject) => {
const newLibs = clone(newObject);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the clone needed? As far as I can see, the returned value replaces existingEntry, at least in setManifestHintsas well as in line 167.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -33,20 +203,121 @@ module.exports = async function({options}) {
}

const buildTimestamp = getTimestamp();
// TODO filter manifest.json if sap/embeds (we expect it contains the correct information)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sap.app/embeds?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

});

// TODO sort!
embeddedInfoMap.forEach((embeddedInfo, libName) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't the keys in the components object component names, not library names?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

// build with --all should not use the version-info.json
// logic needs to be adjusted once selective dependencies are built
// TODO: transient resources (not part of the build result) ( -> skipped for now)
// exclude task if not build --all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

redundant to comment in builder.js

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@tobiasso85 tobiasso85 force-pushed the versioninfo-enrich-with-manifest-infos branch from 8c26c7a to d2e32e8 Compare December 2, 2020 13:52
@tobiasso85 tobiasso85 force-pushed the versioninfo-enrich-with-manifest-infos branch from 6fb5c10 to 61cfd7c Compare December 23, 2020 11:23
@coveralls
Copy link

coveralls commented Jan 4, 2021

Coverage Status

Coverage increased (+0.1%) to 93.835% when pulling daf5610 on versioninfo-enrich-with-manifest-infos into 31a63d9 on master.

@tobiasso85 tobiasso85 force-pushed the versioninfo-enrich-with-manifest-infos branch from e346f0c to e2cb917 Compare January 4, 2021 14:20
@tobiasso85 tobiasso85 changed the title [INTERNAL][WIP] Versioninfo enrich with manifest infos [INTERNAL] Versioninfo enrich with manifest infos Jan 7, 2021
@tobiasso85 tobiasso85 changed the title [INTERNAL] Versioninfo enrich with manifest infos [FEATURE] Versioninfo enrich with manifest infos Jan 13, 2021
*
* @typedef {object<string, object>} ManifestLibraries
*
* * @example
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[minor,jsdoc] one asterisk too much

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with 1fe9c25

* @property {string} name The library name
* @property {string} version The library version
* @property {module:@ui5/fs.Resource} libraryManifest main manifest resources
* @property {module:@ui5/fs.Resource[]} manifestResources list of corresponding manifest resources
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does 'corresponding' mean here? Those found within in the library, but not including the libraryManifest itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with ea58d08

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would separate them and make libraryManifest and embeddedManifest (not including the libraryManifest), this is still open

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

manifestResources do not contain the libraryManifest anymore(874b160)

const embeddedPaths = embeds.map((embed) => {
return getManifestPath(libraryInfo.libraryManifest.getPath(), embed);
});
// sap.x.sdk
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sap.x.sdk ???

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with ea58d08

/**
* Library Info
*
* contains information about the name the version of the library and its manifest, as well as the nested manifests.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... the name and version ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with ea58d08

* libraryManifest: module:@ui5/fs.Resource,
* manifestResources: module:@ui5/fs.Resource[]
* }
* </code>
Copy link
Member

@codeworrior codeworrior Jan 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<code> tags alone don't preserve the formatting, better use <pre>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with ea58d08

*
* @param {Map<string, DependencyInfo>} dependencyInfoMap
*/
const resolveTransitiveDependencies = (dependencyInfoMap) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the variable name libraryInfo misleading. In the current implementation, dependencyInfoMap contains information about libraries as well as embedded components.

But I'm also not sure if this is the way how the Java code works. AFAIK, Maven just cares about the library dependencies. And it first resolves libraries and then resolves the library dependencies of components.

At the end, the result might be the same as we don't add component dependencies to the DependencyInfo objects, but if someone mixes up lib and component dependencies, then the code here won't notice whereas Maven would complain.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in maven the dependencyInfoMap also contains both

But first the library dependencies get resolved, then the components get resolved

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

separated with 1fe9c25

resolve(dependencyInfoMap, lazy) {
if (!this.wasResolved || lazy) {
this.libs.forEach((depInfoObject) => {
const dependencyInfoObjectAdded = this.addResolvedLibDependency(depInfoObject.name, depInfoObject.lazy);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm missing a use of the local lazy here. When the incoming dependency is lazy, even eager dependencies of a component or lib get lazy dependencies of the caller.

The OR in line 254 does something like this, but I wonder why the lazy is needed then.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with f14cba5

}
}
},
"name": "lib.a",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would you mind to make the name the first property? That makes it easier to understand.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with 874b160

* all its dependencies should be treated as lazy
*/
resolve(dependencyInfoMap, lazy) {
if (!this.wasResolved || lazy) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The resolution is kept as state of this instance. It is only updated when lazy is true.
But what when resolve is called again afterwards with lazy = false? Then the result will be the one from the last resolution with lazy = true - which is wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with f14cba5

/**
* Extracted information from a manifest's <code>sap.app</code> and <code>sap.ui5</code> sections.
*/
class ManifestInfo {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the ManifestInfo is not of much use in its current implementation. it just requires copying back and forth data and brings no added value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

used typedef instead with 1fe9c25

improve code by passing correct arguments
adjusted logic to resolve dependencies
adjusted logic to resolve dependencies correctly with regards to lazy
added logic to use info for embeds
improved test
sort keys of objects
refactoring of dependency resolution logic
fix recursive logic such that lazy
property correctly gets interpreted:
* dependencies of lazy dependency are also lazy
* having the same dependency lazy and non-lazy
results in a non-lazy dependency
Rename types to avoid confusion
Rename variable to componentName because it is not the library name
Support embeddedBy property of subcomponents.
hasOwnPreload is set if child and parent component point to each other via
embeds and embeddedBy properties.
* the parent component uses embeds to point to its children
* the child component uses embeddedBy to point to its parent
both paths are relative

- AppIndex expects all nested components to be listed in the
  "sap.app"/"embeds" array of a library's manifest.json, no matter
  whether the corresponding component is bundled with the library or
  in an individual Component-preload bundle
- UI5 runtime needs to know whether a component is bundled as part of
  the library-preload of the containing library. Up to now, it assumed
  this to be the case when the component is listed in
  sap-ui-version.json
- as these two requirements don't match, a new flag (hasOwnPreload) is
  introduced per component in the sap-ui-version.json which indicates
  whether the component has an own bundle or not

The value of the flag is based on the 'embeddedBy' property as declared
in the component's manifest. It is not based on build configuration.
This is in line with the AppIndex's implementation.
Leaving out optional parameters like libraryManifest and manifestResources must
produce the same result as before
use typedef instead of own class for a data container

do embedded component dependencies resolving after library
dependencies resolving in separate step to avoid mixing them up.
use tag <pre> in jsdoc to preserve formatting

Use the same sample across the code e.g. lib.x.sub
manifests and not the library manifest anymore

in the tests adjust expected version info content the
same order of properties as the json string result
would contain for better readability.
compare objects and omit the exact buildTimestamp
but not in project dependencies

improve recursive resolve logic

improve jsdoc for ArtifactInfo

use better structures instead of classes for
* libs and libsResolved
* DependencyInfoObject

Simplify tests
refactor duplicate code to common method
processManifestAndGetArtifactInfo
add tests for versionInfoGenerator with new parameters
* libraryManifest
* embeddedManifests
Copy link
Member

@codeworrior codeworrior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically LGTM. Comments are about potential improvements (opinions about whether those are really improvments might even differ).

Only the point about lazy:false might be worth looking at before a submit.

this.libsResolved[libName] = alreadyResolved;
} else {
// siblings if sibling is eager only if one other sibling eager
alreadyResolved.lazy = alreadyResolved.lazy && lazy;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know I made the proposal to write this as a single line. But now that the libsResolved are used 1:1 for the manifestHints, this has the disadvantage that a lazy:false might appear in the final output, which is unexpected.

Copy link
Contributor Author

@tobiasso85 tobiasso85 Jan 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not only by that line, but with the help of several others and by the nature of the && operator and by JSON.stringify which doesn't stringify an undefined value...

But you're right. I indeed wondered why the tests didn't show any unexpected lazy:false values but was too lazy to investigate this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave it untouched then.

* @param {Map<string,DependencyInfo>} dependencyInfoMap
*/
resolve(dependencyInfoMap) {
if (!this.wasResolved) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Potential simplification] You could use the existence of libsResolved as marker instead of yet another property.

And by making this method work like a getter (return this.libsResolved), the calling code would not have to operate on an internal property of dependencyInfo.

And, by making it a getter, even the resolve loops could disappear in the main method. Calling the getter would be enough to trigger all the necessary calculations.

Copy link
Contributor Author

@tobiasso85 tobiasso85 Jan 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with fd6a8e9
also made libsResolved field "private" by letting it start with underscore

dependencyInfo.resolve(dependencyInfoMap);

// children if parent is lazy children become lazy
Object.keys(dependencyInfo.libsResolved).forEach((resolvedLibName) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Potential simplification] This code pattern

Object.keys(map).forEach((key) => {
  const value = map[key];
  ...
});

occurs several times and (IMHO) reduces readability of the code.
What about

for (const [key, value] of Object.entries(map)) {
   ...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with fd6a8e9



// process library infos
const librariesPromises = options.libraryInfos.map((libraryInfo) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libraryPromises, similar to libraryInfos?

Copy link
Contributor Author

@tobiasso85 tobiasso85 Jan 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean the name?
i would change the name to libraryInfosProcessPromises or artifactInfosPromises

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with fd6a8e9
renamed to libraryInfosProcessPromises

embeddedArtifactInfo.dependencyInfo.resolve(dependencyInfoMap);
});
});

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lines 449 ... 459 could be omitted when resolve would be implemented as a getter for libsResolved(and when that getter would be called by getManifestHints).

Only drawback would be that getManifestHints needs the dependencyInfoMap as parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with fd6a8e9

artifactInfos.forEach((artifactInfo) => {
artifactInfo.getEmbeds().forEach((embeddedArtifactInfo) => {
const componentObject = {
library: embeddedArtifactInfo.parentComponentName
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can embeddedArtifactInfo.parentComponentName ever differ from artifactInfo.name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with fd6a8e9
Put ArtifactInfo as typedef because the parent fields in the child could be retrieved by directly using the parent's fields.

use typedef for ArtifactInfo instead of class
because functionality could be extracted and
it served then only as a data container.

replaced Object.keys().forEach loops which Object.entries loop

Use getResolvedLibraries for directly resolving transitive dependencies
if (manifestDependencies) {
const libs = {};
for (const [libKey, libValue] of Object.entries(manifestDependencies.libs)) {
libs[libKey] = {};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Iteration fails for manifestDependencies.libs === undefined (or null). This was already an issue of the older implementation (using Object.keys). Maybe enrich the if with a second term.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with 8eeab50

return filePath.substr(0, filePath.length - "manifest.json".length) + subPath + "/manifest.json";
}
return filePath;
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the full power of posixPath:

return posixPath.resolve(posixPath.dirname(filePath), subPath, "manifest.json");

@@ -14,6 +16,335 @@ function getTimestamp() {
return year + month + day + hours + minutes;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember what we said about timestamps. UTC or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

handled in separate PR
#348

codeworrior
codeworrior previously approved these changes Jan 26, 2021
Copy link
Member

@codeworrior codeworrior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

const processLibraryInfo = async (libraryInfo) => {
if (!libraryInfo.libraryManifest) {
log.warn(
`Cannot add meta information for library '${libraryInfo.name}'. The manifest.json file cannot be found`);
Copy link
Member

@RandomByte RandomByte Jan 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When executing a ui5 build without --all, this warning appears for all framework dependencies since no manifest.json files are generated for them.

I guess we already discussed that this task doesn't really make sense when executed without --all (hence the new comment in builder.js). But since it is executed in such builds as of today, I find the warning irritating and think it should not appear in that case.

Maybe we need to check whether the has not been supplied at all?

Example from the openui5-sample-app:

> ui5 build
info normalizer:translators:ui5Framework Using OpenUI5 version: 1.85.2
info builder:builder Building project openui5-sample-app not including dependencies...
info builder:builder 🛠  (1/1) Building project openui5-sample-app
info builder:builder application openui5-sample-app 🔨 (1/8) Running task escapeNonAsciiCharacters...
info builder:builder application openui5-sample-app 🔨 (2/8) Running task replaceCopyright...
info builder:builder application openui5-sample-app 🔨 (3/8) Running task replaceVersion...
info builder:builder application openui5-sample-app 🔨 (4/8) Running task generateFlexChangesBundle...
info builder:builder application openui5-sample-app 🔨 (5/8) Running task generateComponentPreload...
info builder:builder application openui5-sample-app 🔨 (6/8) Running task createDebugFiles...
info builder:builder application openui5-sample-app 🔨 (7/8) Running task uglify...
info builder:builder application openui5-sample-app 🔨 (8/8) Running task generateVersionInfo...
WARN builder:processors:versionInfoGenerator Cannot add meta information for library 'sap.ui.unified'. The manifest.json file cannot be found
WARN builder:processors:versionInfoGenerator Cannot add meta information for library 'sap.m'. The manifest.json file cannot be found
WARN builder:processors:versionInfoGenerator Cannot add meta information for library 'sap.ui.core'. The manifest.json file cannot be found
WARN builder:processors:versionInfoGenerator Cannot add meta information for library 'sap.ui.layout'. The manifest.json file cannot be found
WARN builder:processors:versionInfoGenerator Cannot add meta information for library 'sap.f'. The manifest.json file cannot be found
info builder:builder Build succeeded in 574 ms
info builder:builder Executing cleanup tasks...

Without this change, no such warning appears. The application can't resolve this warning, hence it should not be shown to the application developer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with 42ce003
the log is verbose now and does not occur anymore when building the openui5 sample app without --all

* @param {Array} parameters.options.libraryInfos Array of objects representing libraries,
* e.g. <code>{name: "library.xy", version: "1.0.0"}</code>
* @returns {Promise<module:@ui5/fs.Resource[]>} Promise resolving with an array containing the versioninfo resource
* @param {LibraryInfo[]} parameters.options.libraryInfos Array of objects representing libraries,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The LibraryInfo type definition needs to be public as well to be visible in the JSDoc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tackled with daf5610

With regards to backward compatibility the libraryManifest
can be missing.
When --all is omitted the libraryManifest can also be missing.
It is used in the versionInfoGenerator's public JSDoc.
@tobiasso85 tobiasso85 merged commit 7603ece into master Jan 26, 2021
@tobiasso85 tobiasso85 deleted the versioninfo-enrich-with-manifest-infos branch January 26, 2021 17:54

/**
* Resolves dependencies recursively and retrieves them with
* - resolved siblings a lazy and a eager dependency becomes eager
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand this line. Is there anything missing?


/**
* Common type for Library and Component
* embeds and bundled components makes only sense for library
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plural?

*
* @typedef {object} ArtifactInfo
* @property {string} componentName The library name, e.g. "lib.x"
* @property {Set<string>} bundledComponents The embedded components which have a embeddedBy reference to the library
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a --> an

tobiasso85 added a commit that referenced this pull request Feb 26, 2021
Field embeds in created manifest.json file now contains all nested
manifests, independent from the reverse field embeddedBy (embeddedBy
points from an embedded manifest to the library's manifest).

Remove unreachable code (in createSapUI5() -> getUI5Version() function) .

Use path.dirname method to get directory name in findEmbeddedComponents() function.

Use string for version value in manifest (in sectionVersion() function).
e.g. "1.2.3" instead of the semver object's string representation.

It reverts changes which were introduced with #555
Successor of #554
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants