Create and integrate a new task 'generateLibraryManifest' #26
Conversation
codeworrior
force-pushed
the
generate-manifest-json
branch
from
52bfd6d to
acbd0e4
Compare
Pull Request Test Coverage Report for Build 182
💛 - Coveralls |
codeworrior
force-pushed
the
generate-manifest-json
branch
from
abe939e to
8de9c49
Compare
|
Note: the test failures are due to a bug in the ui5-fs project. The bug has been fixed with SAP/ui5-fs#11, which might be part of 0.0.2. |
|
There's yet no ui5-fs release containing that fix. Will create one later today |
The task creates a manifest.json file for libraries that don't have one. It collects the necessary information from the project structure (supported themes, versions of dependencies), from the .library file (name, dependencies, supported themes, thirdparty components, i18n information...) and from an initLibrary call inside the library.js file (implemented controls, elements, types and interfaces, noLibraryCSS flag). An existing manifest.json won't be modified or overwritten.
- refactor test scenario 'library.h' so that the sub-components reside in the namespace of the library - add new test scenario 'library.i' to test manifest creation with data from .library and library.js file - add the newly generated manifest.json to the expected content of the other library test scenarios - enhance all libr<ary test scenarios with a dependency to a fake 'sap.ui.core' lib. For UI5 libs, this dependency is mandatory and manifest generations needs it to determine the UI5 version - fix eslint issues in the new task/processor - fix functional issues in manifestCreator that came up in the tests Change-Id: I02f20c09298d65b2818ec0faeb76252c21d93d91
codeworrior
force-pushed
the
generate-manifest-json
branch
from
8de9c49 to
d1725df
Compare
|
@codeworrior LGTM, I just fixed some minor copy & paste leftovers |
| return workspace.byGlob("/resources/**/.library").then((libraryIndicatorResources) => { | ||
| if (libraryIndicatorResources.length < 1) { | ||
| // No library found - nothing to do | ||
| log.error(`Could not find a ".library" file for project ${options.projectName}. Skipping library manifest generation.`); |
There was a problem hiding this comment.
Do we want this to be an error?
I think most of the libraries developed in the wild doesn't have a .library file as it wasn't used at all except by the maven tooling.
There was a problem hiding this comment.
If we take "manifest first for libraries" serious, we need at least to enforce a manifest.json. So we could check for that and if there's a manifest.json then the .library becomes optional.
But it doesn't have to be this task that complains about it.
There was a problem hiding this comment.
More likely the job of the LibraryFormatter.
The ApplicationFormatter already reads an applications manifest, though it doesn't insist on it.
Also re-classify log message for missing .library file as 'verbose'
|
any chance to get another review? |
|
merci :) |
|
@matz3: when doing this PR, I didn't know about the best practice of exporting everything in |
|
For consistency reasons I would say yes. |
The task creates a manifest.json file for libraries that don't have one.
It collects the necessary information from the project structure
(supported themes, versions of dependencies), from the .library file
(name, dependencies, supported themes, thirdparty components, i18n
information...) and from an initLibrary call inside the library.js file
(implemented controls, elements, types and interfaces, noLibraryCSS
flag).
An existing manifest.json won't be modified or overwritten.