search

CottageLabs / edges

Data query, manipulation, search and visualisation front-end library
MIT License
8 stars 7 forks source link

Build system requirements #40

Open richard-jones opened 3 months ago

richard-jones commented 3 months ago

These are my requirements for any kind of build system we introduce:

  1. It must not add any significant complexity or overhead effort to development. Ideally it would reduce effort.
  2. Must support the ability to produce a build for a client (or other users) which includes only the parts of the code required, with their additional code changes also bundled. We would want a "global" build for the library, and then the ability to easily produce builds which are for specific purposes. There may be more than one "build" for the code in a single project.
  3. Must produce code which is functionally identical to what the developer wrote. It should not be necessary to modify working code to get the build system to produce working code.
  4. Must allow us to have one or more global namespaces declared. That is, at least edges and es but also to allow clients to have global namespaces (e.g. doaj). It should not wrap the resulting built code in an IIFE, or if it does, the IIFE should produce a code module which is mounted on a global namespace, and reflects the structure of the written code.
  5. Must be supported in the developer IDE (at least JetBrains)
  6. Must work well with SCSS/SASS/CSS or ignore it completely and let that be a separate concern
  7. The resulting code must inspect well in the browser. Objects should appear named as they appear in the source, and it should be trivial to map from the line of the source in the browser to the source file in the IDE. It should be possible to add breakpoints in the code as if it is the code in the IDE, and to debug line by line as if in the IDE.
  8. It must be able to handle swappable dependencies. For example, the ES library or the jquery library may need to be swapped for alternative versions either at run-time or build-time. That is import es should be able to accept that es may be one of a selection of possible libraries
  9. It must be capable of producing multiple outputs. For example, if a client has a search page and a data viz page, this should be able to produce two (or more) packages which provide the specific functionality for each page, without bundling additional unrequired code. It may also be desireable to produce 3 outputs in this case: a common library, and then 2 page-specific libraries.
  10. It must support the new style node import syntax, and also accept the old style by-reference function calls. That is import es as per node, or simply a call to es.doQuery where es will be satisfied at run time in the browser.
  11. Similar to 10, it must support libraries which are explicitly always externally referenced. For example, the google maps code retrieved with an API key at run-time.
  12. Transcoding to support older versions of the js runtime would be desireable.
richard-jones commented 3 months ago

@varadekd I've added my requirements for the build if you want to take a look and see how rollup fits the bill.

varadekd commented 2 months ago

@richard-jones I have understood the requirement, I will start working on this once I have completed working on #34.

varadekd commented 2 months ago

@richard-jones

In the current form, it is little hard for us to create the build as per our requirements. As most of the bundle available are module based bundle. I tried using esbuild but the globalName seems to have a little bit of issues which are failing when using it in execution.

Here are two things we can try out, when we are re architecture

  1. Either building the edges as per the build tool.
  2. Building our own builder for edges bundling.