Remove embedding of babel generated js/css. Move to serving with <script src> and <link rel="stylesheet" href>

[jcscottiii]

Is your feature request related to a problem? Please describe. Right now, we embed the css and js on some templates using a custom tag inline.

This came up as part of my work in #2303. After I moved from Django to Flask, all the template tests failed after I changed the inline to jinja2 include. The failure was when using this: {% include "/static/css/main.css" %} , I get jinja2.exceptions.TemplateNotFound: /static/css/main.css. I get similar results for {% include "../static/css/main.css" %}

The cause of the problem: for include to work, it looks within the template_folder. template_folder is assigned to templates. The code that becomes embedded all resides in a folder called static. That folder is a sibling of the templates folder.

Snippet of the current file system. You will see a mix of both static and generated content in the static folder

.
├── static
│   ├── components.js
│   ├── css # <--- generated
│   ├── dist # <--- generated
│   ├── elements
│   ├── img
│   ├── js # <--- generated
│   ├── js-src
│   ├── robots.txt
│   ├── sass
│   └── shoelace
├── templates
│   ├── _base.html
│   ├── accuracy_notice_email.html
│   ├── admin
│   ├── blink
│   ├── estimated-milestones-table.html
│   ├── farewell-rss.xml
│   ├── features.html
│   ├── inactive_user_email.html
│   ├── index.html
│   ├── new-feature-email.html
│   ├── prepublication-notice-email.html
│   ├── review-comment-email.html
│   ├── spa.html
│   ├── test_template.html
│   └── update-feature-email.html

Describe the solution you'd like

Accomplish this 3 steps

Step 1.

Instead, we should serve the javascript and css with

This will prevent runtime errors of a

Benefits of continuing with inline

• It simplifies the number of HTTP requests
• Is necessary for email templates (luckily, our email templates do not use inline)

Benefits of using external scripts

• Can add separate caching policies between html, js and css.
• After the initial load, the browser could be configured to cache the js and css separately. Thus the html downloaded will be smaller since js and css won't be inlined.

Other reasons why to move to serving externally:

• https://stackoverflow.com/a/8284398

Step 2.

Separated generated babel files and actually served static files (e.g. robots.txt) into a public folder

[jrobbins]

I like this.

It would also be good to phase out SASS. I don't think that we use it enough to justify the complexity of having it in our build process. Lit CSS in our lit components (plus standard CSS variables) gives us many of the advantages that initially motivated SASS.

Regarding step 2: I like serving static files and generated files from a directory called static rather than introduce a new public directory. Instead of moving those files, let's move the elements and js-src to the top level.

[jcscottiii]

@jrobbins For step two, what about creating static-src? Underneath would be:

├── static
│   ├── css
│   ├── dist
│   ├── img
│   ├── js
│   ├── robots.txt
│   └── shoelace
├── static-src
│   ├── components.js
│   ├── elements
│   ├── js-src
│   └── sass

As I started to look into this, I saw there would be more folders that needed to be moved out.

[jrobbins]

I like the new organization.

This is kind of a nit, but I'd like it better if the name of the new top-level directory could be autocompleted in one step rather than sharing so many characters with 'static'. How would you feel about calling it client-src, clientside, client, or something else that is descriptive but has a unique prefix? Or, make elements, sass, and js-src top level, then tuck components.js under elements? On the downside, we would lose the obvious relationship between static and the new dir, maybe that's a reason to keep it as you suggested.

[jcscottiii]

I see what you mean with the auto-completion. I will go with client-src