External JavaScripts and CSS

[gdotdesign]

To make it more easier to integrate with other JavaScript sources we should add the ability to add external CSS to the compiled code.

Alongside with this we should change it how it configured in the mint.json file, it should be like this:

{
  "external": {
     "javascripts": ["path/to/javascript"],
     "css": ["path/to/css"]
   }
}

The provided CSS files should be checked the same way the JavaScripts are checked now and they should be added to the compiled CSS.

[s0kil]

@gdotdesign Could we stick with 'javascript' over 'javascripts'?

[gdotdesign]

I'm more comfortable with it's plural form since the user can add more than one and that conveys it more.

css is already in plural form Cascading Style Sheets

[s0kil]

@gdotdesign I have got the CSS and JavaScripts (key, values) parsed.
Where would the CSS be injected in the AST output?

[gdotdesign]

I see two options:

• here is where the CSS gets compiled so I think it can be prepended to that
• during development we can serve them separately and during build time we can copy them over a reference them sepearately

The first option is easier to implement, but the second would be preferable (multiple smaller files instead of one big file)

[s0kil]

reference them separately

<link rel="stylesheet" href="dist/styles-lib.css">?

[s0kil]

I was also thinking if an asset is a link to http(s)://example.com/file.{js, css} then fetch and cache it locally to project level .mint dir.

This would allow managing versions of external libs:

• https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js
• https://raw.githubusercontent.com/instantpage/instant.page/v3.0.0/instantpage.js
• etc...

[s0kil]

But that does not seem necessary, as a user could have Mint + NPM in the same project.

[gdotdesign]

reference them separately

<link rel="stylesheet" href="dist/styles-lib.css">?

yes that was my thinking (maybe put it in a sub folder dist/css/styles-lib.css)

I was also thinking if an asset is a link to http(s)://example.com/file.{js, css} then fetch and cache it locally to project level .mint dir.

I think that is out of scope for this feature. It's much more explicit to have the assets in the repository it will be reproducible even when the CDN does not have the files any more.

[s0kil]

Continuing the discussion in #155
How should we handle external JavaScripts?

• Always link as external script tag
• Provide option in configuration to inline the external library
• Smarter approach could also be, if user specifies multiple external libraries that are small in size, we could merge them into one file. Splitting one large bundle into multiple usually improves loading time, but dozens of network requests could also hurt performance.

[Sija]

Would be nice to be able to choose a desired strategy:

• bundling - useful for HTTP/1.x
• splitting - useful for HTTP/2.0

[s0kil]

@Sija What if I want bundling for HTTP/1.x and splitting for HTTP/(2, 3).x ?

[Sija]

@s0kil good question! I'd build both and serve relevant version on runtime, depending on the request's HTTP version.

[gdotdesign]

I have though about this some:

• found an issue with the current implementation: since packages can have external assets means that serving them from public directory as is is not working:

  Package A depends on package B which have an external asset, when running a dev server for A we need to serve the asset from B

• bundling vs splitting: for assets we can do both, for the compiled code it's trickier but not impossible. I don't think it's the time to think about it, we can do that when we have data on the size of an average project.

• asset order: there can be an issue with dependencies in external assets (for example package A has moment as an assets which package B depends on) how we would handle that?

This is something I need to think about more. The current implementation is like an escape hatch. I don't know if its even should be in the toolchain.

What I can see is that there is a need to make Mint compatible with the existing JavaScript libraries in a package level (mostly bindings). How to make that work is the real challenge here.

[gdotdesign]

With the @asset directive I consider this resolved ☑️