Option to only build certain dependencies

[sebbi08]

Expected Behavior

There sould be an posibility to build only certen Dependencies and not onyl all

Current Behavior

it is only possible to ignore some dependencies in dev mode

Context

• UI5 Module Version (output of ui5 --version when using the CLI): 1.2.1

Affected components (if known)

• ui5-builder
• ui5-server
• ui5-cli
• ui5-fs
• ui5-project
• ui5-logger

The originated problem is that we have a shim for @babel/polyfill

specVersion: "1.0"
kind: extension
type: project-shim
metadata:
    name: babel-polyfills
shims:
    configurations:
        "@babel/polyfill": # name as defined in package.json
            specVersion: "1.0"
            type: module # Use module type
            metadata:
                name: "babel-polyfills"
            resources:
                configuration:
                    paths:
                        /lib/babel/: "dist"

when building we want to build this shim but not all other dependencies. that way we could just zip the dist folder and upload that to the SAP Gateway

[RandomByte]

This makes sense. We could add a CLI parameter like --build-dependency="@babel/polyfill". Would that match your expectation?

[sebbi08]

yea that would be nice but also somehow an configuration option in the yaml file would be nice because when adding another parameter in the end we will have and unreadable npm command.

[RandomByte]

So this dependency can be understood as something the application can't work without?

If yes, I agree that a ui5.yaml configuration would make sense as well. It could define a list of dependencies that must be built when the main project is being built (e.g. via ui5 build).

[sebbi08]

also it would be nice since this dependencie is now allocated via the component namescpce. That it would be included in the Component-preload.js

[jonaszuberbuehler]

@sebbi08 Is there a workaround you are currently using when deploying from Web IDE to an ABAP repo?

[sebbi08]

our workaround was to delete all the unwanted dependencies inside the dist folder before deploying this was only possible with using grunt and from runt utilize the ui5 tooling

[jonaszuberbuehler]

@sebbi08 Ok. I played around a bit with the builder extensions and now I'm copying the defined shims to the dist folder (I'm using core-js-bundle as polyfill):

ui5.yaml:

---
specVersion: '1.0'
kind: extension
type: task
metadata:
  name: copy-shims
task:
  path: lib/copyShims.js
---

copyShims.js:

const log = require('@ui5/logger').getLogger('builder:customtask:copy-shim');

/**
 * Custom task example
 *
 * @param {Object} parameters Parameters
 * @param {module:@ui5/fs.DuplexCollection} parameters.workspace DuplexCollection to read and write files
 * @param {module:@ui5/fs.AbstractReader} parameters.dependencies Reader or Collection to read dependency files
 * @param {Object} parameters.options Options
 * @param {string} parameters.options.projectName Project name
 * @param {string} [parameters.options.configuration] Task configuration if given in ui5.yaml
 * @returns {Promise<undefined>} Promise resolving with <code>undefined</code> once data has been written
 */
module.exports = async function ({workspace, dependencies, options}) {
    const shims = await dependencies.byGlob('/resources/thirdparty/*.js');
    await Promise.all(shims.map((resource) => {
        log.info(`Writing file ${resource.getPath()}`);
        workspace.write(resource);
    }));
};

manifest.json:

"resources": {
    "css": [
        {
            "uri": "css/style.css"
        }
    ],
    "js": [
        {
            "uri": "resources/thirdparty/minified.js"
        }
    ]
}

This could of course be improved but it works for me right now. Maybe useful for you too.

[matz3]

Looks like a valid workaround. But we are definitely looking into providing a better solution for such use cases.
@jonaszuberbuehler: I think you missed a return statement when writing the files (return workspace.write(resource);), so that the Promise.all will wait for that.

[jonaszuberbuehler]

@matz3 True, thx, good catch!

[RandomByte]

@jonaszuberbuehler that's a nice workaround 👍

Thanks for raising our attention again on this issue. Various people also requested this feature on UI5con last Friday (cc @srenwickblum).

We discussed this with some of the team today and think a ui5.yaml configuration would make sense.

Proposal

ui5.yaml:

specVersion: '1.0'
metadata:
  name: my-app
type: application
requiredProjects: # <------------------
  - babel-polyfills # metadata.name of the project
---
specVersion: "1.0"
kind: extension
type: project-shim
metadata:
    name: babel-polyfill-shims
shims:
    configurations:
        "@babel/polyfill":
            specVersion: "1.0"
            type: module
            metadata:
                name: babel-polyfills
            resources:
                configuration:
                    paths:
                        /lib/babel/: "dist"

package.json:

{
  "name": "my-app",
  "dependencies": {
    "@babel/polyfill": "^7.4.4",
    "@openui5/sap.m": "^1.67.1",
    "@openui5/sap.ui.core": "^1.67.1",
    "@openui5/themelib_sap_fiori_3": "^1.67.1"
  }
}

ui5 build: Builds my-app and babel-polyfills
ui5 build --all: Builds my-app, babel-polyfills, sap.m, sap.ui.core and themelib_sap_fiori_3

[jonaszuberbuehler]

@RandomByte Nice!

Two questions:

• We probably shouldn't be using babel/polyfill anymore (deprecated since 7.4.0 https://babeljs.io/docs/en/babel-polyfill), right?
• Do we have to specify the shim in manifest.json as js resource (the way I did it)? This is somehow unclear to me. What are best practices here?

[RandomByte]

We probably shouldn't be using babel/polyfill anymore (deprecated since 7.4.0 https://babeljs.io/docs/en/babel-polyfill), right?

Yes, I saw that as well. I just wanted to stick to the example given by Sebastian.

Do we have to specify the shim in manifest.json as js resource (the way I did it)? This is somehow unclear to me. What are best practices here?

No. This is up to how you want to load the resource. The manifest.json configuration will simply lead to the resources being loaded synchronously upon Component initialization. If you want that, use it. However, I would recommend loading the resource asynchronously using our require APIs somewhere in your application or by other means (i.e. script tag in index.html).
The manifest.json resources configuration does not lead to the referenced resources being bundled.

[jonaszuberbuehler]

@RandomByte Thanks for the clarification!

In the documented example

specVersion: "1.0"
type: application
metadata:
  name: my.application
--- # Everything below this line could also be put into the ui5.yaml of a standalone extension module
specVersion: "1.0"
kind: extension
type: project-shim
metadata:
  name: my.application.thirdparty
shims:
  configurations:
    lodash: # name as defined in package.json
      specVersion: "1.0"
      type: module # Use module type
      metadata:
        name: lodash
      resources:
        configuration:
          paths:
            /resources/my/application/thirdparty/: "" # map root directory of lodash module

what is not pointed out is that EVERYTHING is copied across and not just the main file declared in the lodash package.json:

...
  "main": "lodash.js",
  "name": "lodash",
...

The paths can save a lot of boilerplate code in some cases, but I doubt very much that developers wish to include every js file found in a node_module. It would be nice if I could specifically (instead of a 'catch-all' path) have a "files" section. E.g.

specVersion: "1.0"
type: application
metadata:
  name: my.application
--- # Everything below this line could also be put into the ui5.yaml of a standalone extension module
specVersion: "1.0"
kind: extension
type: project-shim
metadata:
  name: my.application.thirdparty
shims:
  configurations:
    lodash: # name as defined in package.json
      specVersion: "1.0"
      type: module # Use module type
      metadata:
        name: lodash
      resources:
        configuration:
          files:
            /resources/my/application/thirdparty/lodash/lodash.js: "/lodash.js"

I also like the idea that the file defined in the thirdparty's package.json as the main file, is included by default. In otherwords, when resources section in the ui5.yaml is omitted. Then ui5-tooling creates the minified + -dbg.js versions so when not in debug mode, its business as usual (everything minified) but when developers need to debug, all files are readable, including the thirdparty libraries.

I had also hoped for a way to optionally include this single file from the thirdparty library in the component-preload to optimise the loading times in cases where I'm sure I need the library early during startup. It would of course be nice when I have control to choose whether this is bundled in the preload or not.

Right now my only practical choice is to manually copy the specific files I need from node_modules and drop them in a "libs" folder which is automatically swallowed up by the build process. But for me this kinda defeats the purpose of ui5Tooling-build - at least a major aspect of it.

[RandomByte]

Hey @srenwickblum,
I think this is a bit off-topic. However, you should be able to use the builder.resources.excludes configuration to exclude everything but lodash.js. With this, when using ui5 serve (= development) you would still have all resources of the lodash module available. Only the build result is being reduced.

We don't make much use of package.json configuration because it might mean something different depending on the package. Yet it would add another layer of complexity to a projects configuration.