> Can Webpack be made to build a library under a hidden (shaded) namespace,
with core consuming the private version?
You explicitly have to configure things to make bundled libraries global.
by default require("") statements are localized, so `const $ =
require('jquery')` would not make it public.
looking at
https://github.com/atomiks/tippyjs/blob/ad85f6feb79cf6c5853c43bf1b2a50c4fa98e7a1/src/createTippy.ts#L1
if tippy is being required, it should be properly self contained, but if
its being loaded as a generic <script> tag, it probably depends on
versions attached to window.
looking at
https://github.com/jenkinsci/jenkins/blob/d5cf94affc4424fc32e2de76a3a1a9dc3b8ef8ff/war/src/main/js/components/tooltips/index.js#L1
it should be required property
that being said, I also see
https://github.com/jenkinsci/jenkins/blob/d5cf94affc4424fc32e2de76a3a1a9dc3b8ef8ff/war/pom.xml#L407
which looks to be an import but in the way basil already wanted?
I tried accessing "Popper.createPopper" on ci.jenkins.io and it doesn't
seem to be defined, so I don't think its exposed?
On Tue, May 23, 2023 at 10:04 AM Basil Crow <m...@basilcrow.com> wrote:
> On Tue, May 23, 2023 at 12:28 AM Ullrich Hafner
> <ullrich.haf...@gmail.com> wrote:
> > In JS and CSS and Jelly we have no concepts of encapsulation and APIs in
> the
> > moment. Everything what is available in the browser is public by
> default. In
> > JS this is even more complex to hide than in Java.
>
> Can Webpack be made to build a library under a hidden (shaded) namespace,
> with
> core consuming the private version?
>
> > I think that users also will benefit from views that do not load the same
> > library multiple times (loading time of a page). Also it duplicates the
> > development effort if we create a plugin API for each JS library that we
> are
> > using in core.
>
> These are indeed benefits, but I think the maintenance costs of exposing
> core
> libraries to plugins are higher. This is a serious problem in every modular
> system that fails to hide its internal implementation details from
> consumers;
> see, for example:
>
>
> http://dtrace.org/blogs/wesolows/2014/04/10/libsunw_ssl-or-how-smartos-avoids-sadness/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjoeFbXySnWOXhXhDLbeksKQkxbbB%2B%2Bbpo_bBme1WkK%3D-Q%40mail.gmail.com
> .
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuvjOBrWZew3%2BZn5VAJmZrgsa%2BMZJ%2BnoBZ23OvHuUPfwkA%40mail.gmail.com.
