Introducing `core-es` package

[elsassph]

Following discussions on https://github.com/rdkcentral/Lightning/issues/501 with @frank-weindel, in order to address https://github.com/rdkcentral/Lightning/issues/490, I believe we should have 2 explicit libraries:

• @lightningjs/core - the current library
• @lightningjs/core-es - a pure ES library, optimal for tree-shaking

PR has 2 commits:

1. Reorganises project into "packages", with current core library source moved under packages/core
2. Adds package/core-es

The idea is that from this one repo, the 2 packages could be published.

[rdkcmf-jenkins]

Blackduck scan failure details

Summary: 0 violations, 0 files pending approval, 2 files pending identification.

• Protex Server Path: /home/blackduck/github/Lightning/503/rdkcentral/Lightning

• Commit: 575ccd764f3943ac2894093062fc53724e3606dc

  Report detail: gist

[elsassph]

Is it maybe too radical? It can be made to work as a standalone repo with a build step pulling this repo.

[rdkcmf-jenkins]

WARNING: A Blackduck scan failure has been waived

A prior failure has been upvoted

• Upvote reason: treat as own (i.e. Metrological) code

• Commit: 575ccd764f3943ac2894093062fc53724e3606dc

[frank-weindel]

Thanks for submitting this @elsassph. I discussed with the team and we'd like to go with the simpler approach you laid out in #501. Is that something you'd be willing to revive?

[elsassph]

Thanks @frank-weindel. What about a separate repo for the ES exports?

There is a real concern IMHO that someone mistakenly imports both the global lng object and the ES source (VS Code can easily import it automatically) - which would unexpectedly significantly increase the size of a project.

[frank-weindel]

We would still transition to using the full source tree (built to dest) for the original ESM export. The new pure ESM export would import from that same source tree. So the worst that should happen is that users who mix will get all of Lightning in their bundle, as if they had just used the original ESM export anyway.

I'm not sure how much a separate repo would help. In any case, if a user installs it (assuming it's dependent on @lightningjs/core) and then installs an existing component library that still uses the @lightningjs/core's original ESM export they will be in the same boat as above.

As you've been able to utilize tree shaking in past Lightning versions without a separate package, what in your opinion would be the best way for you to achieve that again? I'm assuming your project does not use the Lightning SDK nor the two component libraries we have published in RDK Central as they use the original Lightning/'lng ESM export.