#245 Bundle patternfly.min.css and patternfly.min.js within application sources
Closed 6 years ago Opened 6 years ago by clime.

While xstatic-patternfly-common is pretty cool package, it makes my life slightly more difficult as a developer. I run copr-frontend directly from sources without building and installing it every time I make a change. Currently it leads to this:

Screenshot_from_2018-02-22_10-57-03.png

We already bundle lots of stuff in the application so I wouldn't worry that much about bundling at least patternfly.min.js and patternfly.min.css in addition. Do we need anything else from xstatic-patternfly-common? If we need some images or icons, then we can use it the approach of copying just those into copr-frontend application during build-time. If not, I think we can stop using xstatic-patternfly-common.

By the way, we definitely do not need: Requires: xstatic-patternfly-common.


Btw. I tried to workaround my issue by setting up symbolic links from /usr/share/javascript/patternfly to ~/copr/frontend/coprs_frontend/coprs/static/. But the problem is that e.g. ~/copr/frontend/coprs_frontend/coprs/static/js directory already exists in our codebase so I would need to make this workaround much more complicated. If we need it, I would really opt xstatic-patternfly-common only for images or png icons.

In addition to patternfly.min.js and patternfly.min.css, we need patternfly-additions.min.css for graphs.

In addition to patternfly.min.js and patternfly.min.css, we need patternfly-additions.min.css for graphs.

Okay, I would suggest including those three files directly in the application sources and dropping xstatic-patternfly-common. It's around ~350KB of data, which is a lot but given that our components dir currently has:

8.6M    components

I would go for it anyway.

I want to investigate this, so please give me at least some before bundling it.

We already bundle lots of stuff in the application so I wouldn't worry that much about bundling

So because we are already bundling we should stop caring about bundling? :(

By the way, we definitely do not need: Requires: xstatic-patternfly-common

Fonts including glyphicons. *.less files, spinners.

Because....?

We already bundle lots of stuff in the application so I wouldn't worry that much about bundling

So because we are already bundling we should stop caring about bundling? :(

Do you have a better solution? This is not just a case for me but for anyone who would want to run copr-frontend e.g. in virtualenv. If you have a better solution then I am all for it.

By the way, we definitely do not need: Requires: xstatic-patternfly-common

Fonts including glyphicons. *.less files, spinners.
Because....?

No idea what you mean here.

I'm wholeheartedly against any bundling. I'm not sure I understand the issue in
description though.. why the symlinks doesn't work?

I was curious how the selinux works when we have Requires: xstatic-patternfly-common
and we actually not using that package at all since there's:
cp -a %{_datadir}/javascript/patternfly %{buildroot}%{_datadir}/copr/coprs_frontend/coprs/static/components/

in spec file. So we are actually bundling. Would it be possible to propose some
fix for xstatic-patternfly-common so we wouldn't have to bundle?

What if we have a condition in our templates (or use macro containing such condition)

{% if config.DEBUG %}
    Render links to some online files
{% else %}
    Render links to files provided by xstatic packages
{% endif %}

Metadata Update from @clime:
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata
Attachments 1