+1 for removing it.

> The status quo does not seem sustainable to me.
Agreed. If we want to investigated into frontend tests in the future, we 
should use something more maintainable, rather a bunch of standalone 
repositories bundling ancient or detached plugins.
Could likely archive all these repositories if there's no need and demand 
to keep them up.

> Also on a side note, does the project have access to that scope?

All packages are published under a personal 
account, https://www.npmjs.com/~tfennelly, https://www.npmjs.com/~jenkinsci 
may also be operated by tfennelly.

On Friday, 22 July 2022 at 18:52:09 UTC+2 [email protected] wrote:

> For lazy(mobile) people like me
>
> https://issues.jenkins.io/browse/JENKINS-68975
> https://issues.jenkins.io/browse/JENKINS-69070
>
> The first feels like the jquery package just doesn't export a cjs file. So 
> possibly just needs updating. I probably could rewrite it to use modern js 
> and no jquery.
>
> I'm totally 100% in favor of removing all the @jenkins-cd modules that 
> were created for blueocean. They are a frustrating mess.
>
> Also on a side note, does the project have access to that scope? I'm going 
> to be making a helpdesk ticket soon to see if I can get access to one of 
> the Jenkins npm accounts/orgs
>
>
>
> On Fri., Jul. 22, 2022, 9:39 a.m. Basil Crow, <[email protected]> wrote:
>
>> The frontend in core has exactly two (2) unit tests:
>>
>> war/src/test/js/pluginSetupWizard.spec.js
>> war/src/test/js/widgets/config/tabbar.spec.js
>>
>> Both of these date from 2016. They use an old version of Jest from
>> https://jestjs.io and @jenkins-cd/js-test from
>> https://github.com/jenkinsci/js-test which has not been updated since
>> 2016. Newer versions of Jest require significant changes in consumers
>> as described in JENKINS-68975. @jenkins-cd/js-test has many
>> problematic transitive dependencies as described in JENKINS-69070.
>>
>> I could not find any usages of the @jenkins-cd/js-test framework in
>> plugins beside Blue Ocean, which is not being actively developed and
>> dates back to the same time period.
>>
>> The status quo does not seem sustainable to me. While resolving
>> JENKINS-68975 and JENKINS-69070 are not out of the question, I wonder
>> whether we feel that the expected value to be gained is worth the
>> trouble. Recall that there are only two such tests in core, so I feel
>> the value being provided by them is minimal.
>>
>> Perhaps it is time to declare the end of this particular journey and
>> delete these two tests, the use of Jest in core, and the use of
>> @jenkins-cd/js-test in core. If such a framework is desired, it might
>> be easier to start over rather than to modernize the existing
>> framework. The advantage would be a much simpler dependency tree and
>> easier maintenance. The disadvantage would be losing these two tests,
>> one for the setup wizard and one for some sort of tab bar.
>>
>> I am inclined to vote in favor of ripping this out, unless someone
>> wants to take on JENKINS-68975 and JENKINS-69070. Does anyone have any
>> thoughts about this?
>>
>> -- 
>> 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 [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpsBCRAptHcou6nreTUU4UTy%2BwifV2pc9U-YXnhNdNZUA%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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/60759c57-385d-4f11-9c3f-42129f886570n%40googlegroups.com.

Reply via email to