Create a streamlined bundle optimised for Web/AST users

[dselman]

Feature Request 🛍️

Although we web pack concerto-core today, it is quite large, mostly due to the inclusion of the CTO parser, coming from concerto-cto.

Use Case

Users using the ModelManager with AST (JSON) files only, particularly in a memory constrained environment, like the web browser.

Possible Solution

It would be useful to build a package that was essentially concerto-core, but without concerto-cto. This would break the ModelManager.addCTOFile method but the rest of the implementation should work.

Context

Detailed Description

[RINO-GAELICO]

Hi @dselman, I'd love to tackle this issue. Any ideas where I should start looking?

[RINO-GAELICO]

Hi @dselman, I created a new package called concerto-core-essential based on concerto-core. I removed the concerto-core dependency form package.json and I modified the webpack.config.js accordingly.
I then ran npm install and it seems to install the package correctly. What other steps do you recommend me to take?
Thank you

PS I know it's not October quite yet, but I would like to do this as one of the Hacktoberfest contributions

[dselman]

Hey @RINO-GAELICO that sounds very promising!

One of my concerns is long-term maintenance of the packaged; we want to ensure that the overhead of adding another bundle to our build/publish is minimal, and as automated as possible.

I can see a couple of options:

1. We create a new package concerto-runtime (?) that is concerto-core, minus the dependency on concerto-cto and the ModelManager. The ModelManager that we'd export from this package would be BaseModelManager.
2. We'd need to do some surgery on the unit tests for concerto-runtime so that the tests using CTO files (most!) continued to work. E.g. we could create a TestModelManager that would depend on concerto-cto and the parser (as a dev dependency).
3. Refactor concerto-core to depend on concerto-runtime.

Alternatively perhaps there is some web pack build config that we can use to generate the concerto-runtime package as well as concerto-core - doing some surgery on the dependencies in the build. This would mean that our development process could continue to be based on concerto-core, with concerto-runtime purely generated by the npm scripts prior to publishing.

I think an analysis of these options (plus others?) would be useful first — we can then validate the best way to proceed at a working group call.

[RINO-GAELICO]

Hi @dselman, thanks for the thorough explanation. It seems that adding a new package might not be the best approach, since it would increase the maintenance burden.
On the other hand, generating the concerto-runtime package via npm scripts would avoid significant refactoring and the need to maintain multiple separate packages.

Shall we move forward in that direction?

[RINO-GAELICO]

Hi @dselman,

If we proceed with the option of modifying the webpack config, can we use two different entry points? If so, would that mean we would need to have two different index.js files?

Alternatively, we could use two separate webpack config files.

Please let me know what are your thoughts on this