search

accordproject / concerto

Business schema language and runtime
https://concerto.accordproject.org
Apache License 2.0
121 stars 106 forks source link

Create a streamlined bundle optimised for Web/AST users #914

Open dselman opened 1 month ago

dselman commented 1 month ago

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.

image

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 commented 1 month ago

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

RINO-GAELICO commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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